-
Notifications
You must be signed in to change notification settings - Fork 3.4k
Revert removal of createRequire
#23265
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
Conversation
29fac54 to
66c5f53
Compare
|
What is the advantage? On code size it doesn't seem to help here IIUC |
|
See #23169 (comment). We have a lot of uses of |
|
I see, but if it's fixing a regression, why doesn't code size improve here? Or is the regression not covered by existing tests? |
This change effectively reverts emscripten-core#23169 because it turns out there are quite a few other places in the codebase that depend on being able to call `require`.
The regression is not covered by the existing tests. We would need to add tests that target each of our The code size regressions are pretty minor and bascially the inverse of the improvments from #23169 |
66c5f53 to
27c3d08
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Got it, thanks, sounds good.
For most uses of `require()` in emscripten this does not matter since we load mostly system libraries. However for the `ws` module it is needed. This bug was being masked by the fact that we were setting `NODE_PATH` in our socket test running. This is no longer needed now that we run (non-parallel) tests in the emscripten tree (in out/test). This is followup to emscripten-core#23265 which itself was an attempt to revert 23169. Fixes: emscripten-core#23503
For most uses of `require()` in emscripten this does not matter since we load mostly system libraries. However for the `ws` module it is needed. This bug was being masked by the fact that we were setting `NODE_PATH` in our socket test running. This is no longer needed now that we run (non-parallel) tests in the emscripten tree (in out/test). This is followup to emscripten-core#23265 which itself was an attempt to revert 23169. Fixes: emscripten-core#23503
For most uses of `require()` in emscripten this does not matter since we load mostly system libraries. However for the `ws` module it is needed. This bug was being masked by the fact that we were setting `NODE_PATH` in our socket test running. This is no longer needed now that we run (non-parallel) tests in the emscripten tree (in out/test). This is followup to emscripten-core#23265 which itself was an attempt to revert 23169. Fixes: emscripten-core#23503
For most uses of `require()` in emscripten this does not matter since we load mostly system libraries. However for the `ws` module it is needed. This bug was being masked by the fact that we were setting `NODE_PATH` in our socket test running. This is no longer needed now that we run (non-parallel) tests in the emscripten tree (in out/test). This is followup to emscripten-core#23265 which itself was an attempt to revert 23169. Fixes: emscripten-core#23503
For most uses of `require()` in emscripten this does not matter since we load mostly system libraries. However for the `ws` module it is needed. This bug was being masked by the fact that we were setting `NODE_PATH` in our socket test running. This is no longer needed now that we run (non-parallel) tests in the emscripten tree (in out/test). This is followup to emscripten-core#23265 which itself was an attempt to revert 23169. Fixes: emscripten-core#23503
For most uses of `require()` in emscripten this does not matter since we load mostly system libraries. However for the `ws` module it is needed. This bug was being masked by the fact that we were setting `NODE_PATH` in our socket test running. This is no longer needed now that we run (non-parallel) tests in the emscripten tree (in out/test). This is followup to #23265 which itself was an attempt to revert #23169. Fixes: #23503
This change effectively reverts #23169 because it turns out there are quite a few other places in the codebase that depend on being able to call
require.