Repository navigation
support output.libraryTarget: 'module' #2933
Description
I'm submitting a feature request
It would be nice, if output.libraryTarget could support the ES2015 module format.
What is the motivation / use case for changing the behavior?
Say I develop a fancy component called fancy-component with webpack. I use a very custom config with specific loader settings e.g. for inlining images and stuff like that. My module exports FancyComponent and BigFancyComponent.
A friend develops a single page application and uses rollup to do that. He knows nothing about webpack, but wants to use my FancyComponent, but not BigFancyComponent. He installs fancy-component and imports FancyComponent. BigFancyComponent should not be included in the build (because of tree shaking).
As far as I know this is currently not possible. My friend would need fancy-component in a format using ES2015 modules. But currently these include webpack specific loader logic. I really need to publish fancy-component without webpack specific logic, but with ES2015 modules.
Activity
TheLarkInn commentedon Aug 30, 2016
I definitely see the merit in this. @sokra I don't think we have a way already to export vanilla es2015 / es modules. I think that maybe this can be part of the rollup story (module combining/(and this splitting exporting)).
donaldpipowitch commentedon Oct 13, 2016
Is there anything I can do to help with that? Can I tackle this problem myself as someone who is unfamiliar with webpacks code base? Or is this a rabbit hole into the guts of webpack? :)
TheLarkInn commentedon Oct 13, 2016
For a feature like this we should write up the design for the feature. Questions I think should be answerered first:
TheLarkInn commentedon Oct 13, 2016
Once we have the behavior designed then you can go straight into adding the test cases.
donaldpipowitch commentedon Oct 13, 2016
Seems to be like big step. Could we introduce some workaround in the meantime? Like emitting plain non-bundled commonjs modules without
__webpack_require__,webpackBootstrap, etc.?Use case is similar. I want to build a project with webpacks powerful loaders and I want to output some sort of modules without webpack specific logic, so that they can be consumed more easily by third party build tools. (Or webpack itself, too! E.g. I can't consume CommonJS modules outputted from webpack right now and use
process.env. A good example: https://github.com/facebook/react is created as CommonJS and they use ``process.env.NODE_ENV. Their"main"` file points to the CommonJS entry. They can only do that, because they don't use webpack in the first place. If they would want to include a loader somewhere, they currently couldn't emit a target like they have right now which doesn't force others to use webpack, too.)donaldpipowitch commentedon Oct 14, 2016
Turns out... it looks like I already can output CommonJS modules and keep
process.env. (From my knowledge using CommonJS - or ES2015 modules in the future - and allowing environment variables is the lowest common denominator between current popular bundlers. Other features like loaders are webpack-specific.)You need to set
output.libraryTarget: 'commonjs2'(I guess most webpack users know this) and you need to set something likenew DefinePlugin({ 'process.env.FOO': 'process.env.FOO' })(that was new to me). So it should be possible to create a lib with webpack which can still be consumed by other bundlers without loosing the feature of setting environment variables.The only feature which isn't supported in that way is tree shaking, which brings me back to the original feature request.
nadavsinai commentedon Jan 19, 2017
@donaldpipowitch thanks for bringing this up, very useful indeed, I would love to contribute too, I am going to try to learn the current code base first...
nathanosdev commentedon May 10, 2017
Would love to this implemented!
HipsterZipster commentedon Sep 27, 2017
Have there been any updates to this issue in the past year? Is it being tracked elsewhere?
yansern commentedon Sep 28, 2017
Having to learn both webpack and rollup is no fun! Would love to have this implemented in webpack.
179 remaining items
WalterWeidner commentedon Feb 3, 2023
How likely is this to be implemented? We might need to adjust our build to use something else if this is unlikely to happen.
10Derozan commentedon Feb 21, 2024
Any updates? I want to use it for libraries, too
tonysamperi commentedon Mar 7, 2025
Seriously? It's been almost 10 years now?
I used it for a library, but it turned out it wasn't tree-shakeable...
I found a solution using tsc, which means I'll need to go back to rollup (that I used in older versions!!)..
Very disappointed.
Kocal commentedon Mar 8, 2025
@tonysamperi we are waiting for your PR then
tonysamperi commentedon Mar 8, 2025
@Kocal your reply is simply disappointing as well.
If you really need a hand to understand how to tackle this I'm happy to help.
Sarcasm won't solve this problem.
If the main contributors can write up a document explaining what is blocking this (I assume there's something besides the non esm dependencies)...
Maybe the readers of this issue can help find solutions...
goloveychuk commentedon Mar 8, 2025
Tldr use esbuild or rollup.
Long version.
To make tree shaking works, bundle should generate flat output. Which means that all imported functions or variables should be rendered in top level of output module.
This is what esbuild and rolldown outputs (and probably rollup, I haven't check it personally).
Webpack, instead, generates registry of modules. Every module (file) is registered in big hashmap, all imports are done via webpack runtime calls.
Obviously, this could not be treeshaked.
This is opinionated decision sokra made. It has pros and cons.
E.g debugging is simpler because all module local members are scoped in function. Other one is that main chunk could provide common modules for async chunks via registry. Esbuild instead will generate additional chunk for commons.
But the point is that it's a core principle of how major of webpack works. This affects chunks generation e.g.
Thats why (as I see it) esm is still an issue. But I wouldn't expect it will be fixed in webpack anytime. Especially after sokra (afaik) switched developing turbopack.
Generally I would look on it as it's out of webpack scope (because, it's main target is spa prod bundle, not libs).
This is my imho.
tonysamperi commentedon Mar 9, 2025
hey @goloveychuk,
first of all thank you for a such detailed explanation.
I think I understand, but at this point I would close the issue, explaining this cannot be achieved, as it goes against the purposes of webpack itself.
For what concerns my library, I'll explore esbuild (I'm intrigued by performances), or go back to rollup.
Cheers
alexander-akait commentedon Mar 10, 2025
@goloveychuk
For the most part we support it, but we don't generate "treeshaked output". This is not our primary goal at the moment, although it may well be realized in the future.
goloveychuk commentedon Apr 29, 2025
@alexander-akait btw I see https://github.com/webpack/webpack/releases/tag/v5.93.0
modern-moduleoption is added. Isn't it suppose to fix tree shaking issue?alexander-akait commentedon Apr 29, 2025
@goloveychuk
treeshaked outputis working formodern(modern-moduleis an alias) too right now, but you should have ECMA modules source codesgarfinkel commentedon Aug 15, 2025
It doesn't fully work.
asset/resourcestill persistently emits the__webpack_require__iife which is not tree-shakeable.alexander-akait commentedon Aug 17, 2025
@sgarfinkel Weird, can you provide reproducible test repo?
alexander-akait commentedon Sep 1, 2025
Let's close because we already support ES modules output, we have an issue to improve and make some things better - #17121