-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Dropping require-kernel and yajsml #4820
Comments
Is there any ETA for fixing this? I have etherpad inside an iframe (different origins) and then it doesn't work on Chrome. Though it works with same origins, but for my particular case it is not option. Related error:
|
Not yet. We have seen your error before but it was a nginx misconfiguration. #4976 |
Thank you that seems to solve the issue! As a note for others with the same problem, put the |
Thanks!! Would you be so kind and test if it works with #4990 And btw: Which version of chrome and what operating system? I wasn't able to reproduce this even with the imo latest version |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
This is intended as a collection of useful information/discussion re migration to a better bundler like webpack or snowpack.
Old PoC for removing require-kernel: #3603
Some useful todo that should be covered: #3505
Maintained plugin for bundling plugins: https://github.com/storytouch/ep_webpack
imo it's best if we'd integrate bundling directly into core and cover plugins. Rebundling should only happen on the first start of core, after updating core or changing files in ./src, or after installing/deinstalling plugins. I'm not sure if we should support
minify:false
any longer. I think proper support for source maps would be enough.We need to decide if we want a separate build step (it could be run on start/restart from within etherpad) or if we bundle files on demand. It needs to be investigated if the bundler in non-cli mode is as comprehensive as it's cli counterpart.
imo we should also think about moving to ESM. I imagine this to be unrelated to bundlin, ie move from CommonJS to ESM first, then think about bundling (hopefully the bundler comes with a transpiler to optionally support browser that don't support ESM yet - however only IE seems to be affected). The goal should be to enable plugin devs to easily migrate to ESM, maybe an automated script, or ESM wrapper and it would be cool if /admin/plugin would support something like "show/install the most recent compatible version of this plugin". Best would be, if core would support legacy plugins for a longer period. This needs investigation.
Because we probably need to rethink what we want to export to make this happen, there is a relation to #4714
Also related:
.js
files #4401)The text was updated successfully, but these errors were encountered: