-
-
Notifications
You must be signed in to change notification settings - Fork 600
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
[Feature]: Consider supporting webpack.config.mjs alongside webpack.config.js #282
Comments
The problem here is not This is because webpack has to be able to recover from not being able to import Although, since it is |
You could use the --config-register flag? |
@ev1stensberg I think we're missing docs for that flag. |
@TomasHubelbauer Till we add it to the docs, you can try doing what @jdalton has mentioned here. |
He doesn't really mention the actual command. Just do |
Did someone on the thread answer/fix your issue @TomasHubelbauer ? |
This is a feature request, the way I understand it, there are some ideas floating around and maybe the issue will get triaged for feasibility and put on a roadmap? To be clear, I am not blocked or anything by not being able to do this right now, I'd just like to see it be a possibility in the future. |
Cause I think it's doable, if you run |
https://github.com/standard-things/esm can be used for this feature |
@ev1stensberg @montogeek Thanks, I'll try that out! |
In webpack 4 you can use its webpack -r esm @babel/register or webpack -r esm -r @babel/register |
Thanks for clearing up @jdalton , closing this now, as the issue/feat has been solved ( ? ) |
It would still be cool if this worked out of the box and was built it to WebPack, but custom config loader is a good option. |
That's not a fix, that's a workaround that's done by emulation. It's not loading native modules. |
One thing we could do is to detect .mjs endings and use webpack with std/esm instead? |
That'd just be blessing the workaround. The only valid fix that won't require users not using the feature to enable experimental modules is |
If the eval turns out false, we can fall back to |
Yeah, if the |
/** @param {string} modulePath */
function tryImport (modulePath) {
try {
return eval(`import(${JSON.stringify(modulePath)})`);
} catch (e) {
// import() not supported on the currently executing node
return Promise.resolve().then(() => {
// optionally try the @std/esm stuff here if desired
const result = require(modulePath)
if (typeof result !== 'object' || result === null || !result.__esModule) {
// this is technically supposed to be cached but there probably won't be any
// harm not to cache it in this use case
result = Object.create(null, { default: { value: result, enumerable: true } })
}
return result
})
}
} Note that the |
|
I think we should put this for chill on now, eval is not a good thing and using the eval code for a rejected promise would mean a lot of work to get it right and tight. We could spawn a child process to get the config through esm/std once we're more laid up for it. |
node 13.2 has been released with .mjs support without flag: https://github.com/nodejs/node/releases/tag/v13.2.0 can we think about use |
Definitely, are you able to test it against |
@evenstensberg I am happy to participate in the test. What kind of tests do I need to do? |
This needs an update as node has officially released modules without a flag (albeit experimental) Node is heading towards ESM over the next few years, so this needs to be addressed. |
tried to test have an error
|
Few months later. Any update? I think supporting modules in |
I had to drop Edit: Back on |
Let's close in favor #1622, temporary workaround #1622 (comment) |
Do you want to request a feature or report a bug?
Feature.
What is the current behavior?
webpack.config.mjs
cannot be used in place ofwebpack.config.js
.What is the expected behavior?
webpack.config.mjs
could be used instead ofwebpack.config.js
.If this is a feature request, what is motivation or use case for changing the behavior?
Consistency.
This issue was moved from webpack/webpack#6566 by @sokra. Orginal issue was by @TomasHubelbauer.
The text was updated successfully, but these errors were encountered: