-
Notifications
You must be signed in to change notification settings - Fork 172
Default module name normalizer wrongfully assumes QJS libc/runtime environment #650
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
Comments
I did think of that but chose to "see what happens" since we'd basically need 99.9% the same normalizer, and since everyone uses namespaces imports I thought it should be fine... |
Maybe just revert that change? It's really only relevant for qjs (and maybe qjsc?), embedders can name modules whatever they want when they initialize them. |
Let me try to move it to cutils so we can use it in both places. If it feels wrong we can just revert. |
I went with a revert: #662 |
Hey,
I saw this PR introduced some backwards compatibility features in the default normalizer:
https://github.com/quickjs-ng/quickjs/pull/618/files#diff-45f1ae674139f993bf8a99c382c1ba4863272a6fec2f492d76d7ff1b2cfcfbe2R26271-R26279
This change introduces issue and potential bugs for users running only quickjs engine, but not runtime.
For instance if we register a "os" module in rquickjs and not using a custom normalizer we'll get warning about qjs prefix which is completely irrelevant.
Correct solution would be to to register a custom normalizer in quickjs-libc that handles this case, or ignore the backwards compatibility.
The text was updated successfully, but these errors were encountered: