-
Notifications
You must be signed in to change notification settings - Fork 13
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
Provide an ES6 build of ospec #25
Comments
For now, I'd recommend using |
I think node uses esm internally so I don't see a difference. |
It does everything natively.
You still have to pass |
Yeah, sorry, I got confused, I thought the flag is only needed for static imports. I could also try to do it if you agree but it would need some trick to pass a way to import things dynamically. If I understand your proposal to use esm correctly, you say I could dynamically use it (rather than with |
Now that I take a closer look, it appears v12.x has it enabled by default. So it does appear possible. I would still need to modify tests first to ensure it still works.
And for using |
Node 14 has it by default at least. |
I quickly tried to use |
There are three different scenarios which require different imports: node with commonjs, node with es modules and browser (assumed to have es modules or be transpiled). Previously ospec would break if executed in a module context, build systems are also not able to fix that because require is used dynamically. This commit changes how exports are defined to handle all three scenarios. Now build systems can detect what is required and node will pick appropriate version.
There are three different scenarios which require different imports: node with commonjs, node with es modules and browser (assumed to have es modules or be transpiled). Previously ospec would break if executed in a module context, build systems are also not able to fix that because require is used dynamically. This commit changes how exports are defined to handle all three scenarios. Now build systems can detect what is required and node will pick appropriate version.
There are three different scenarios which require different imports: node with commonjs, node with es modules and browser (assumed to have es modules or be transpiled). Previously ospec would break if executed in a module context, build systems are also not able to fix that because require is used dynamically. This commit changes how exports are defined to handle all three scenarios. Now build systems can detect what is required and node will pick appropriate version.
There are three different scenarios which require different imports: node with commonjs, node with es modules and browser (assumed to have es modules or be transpiled). Previously ospec would break if executed in a module context, build systems are also not able to fix that because require is used dynamically. This commit changes how exports are defined to handle all three scenarios. Now build systems can detect what is required and node will pick appropriate version.
There are three different scenarios which require different imports: node with commonjs, node with es modules and browser (assumed to have es modules or be transpiled). Previously ospec would break if executed in a module context, build systems are also not able to fix that because require is used dynamically. This commit changes how exports are defined to handle all three scenarios. Now build systems can detect what is required and node will pick appropriate version.
There are three different scenarios which require different imports: node with commonjs, node with es modules and browser (assumed to have es modules or be transpiled). Previously ospec would break if executed in a module context, build systems are also not able to fix that because require is used dynamically. This commit changes how exports are defined to handle all three scenarios. Now build systems can detect what is required and node will pick appropriate version.
There are three different scenarios which require different imports: node with commonjs, node with es modules and browser (assumed to have es modules or be transpiled). Previously ospec would break if executed in a module context, build systems are also not able to fix that because require is used dynamically. This commit changes how exports are defined to handle all three scenarios. Now build systems can detect what is required and node will pick appropriate version.
This can be worked around without producing an ES Module version, by calling Fixed in master :-) |
Hi
Thanks a lot for making and supporting ospec.
I would like to ask you to provide ES6 version of ospec.
We are currently in the process of migrating to Rollup and we try to use native ES6 modules for development, in both web and node versions. To use ospec we use
@rollup/plugin-commonjs
which transforms commonjs module into ES6 module (or tries its best to do so). Unfortunately it cannot do much with dynamicrequire()
for theutil
which is not allowed when the file is treated as ES module. What could be used for ES there is dynamicimport()
.The text was updated successfully, but these errors were encountered: