support output.libraryTarget: 'module' #2933
I'm submitting a feature request
It would be nice, if
What is the motivation / use case for changing the behavior?
Say I develop a fancy component called
A friend develops a single page application and uses rollup to do that. He knows nothing about webpack, but wants to use my
As far as I know this is currently not possible. My friend would need
The text was updated successfully, but these errors were encountered:
For a feature like this we should write up the design for the feature. Questions I think should be answerered first:
Seems to be like big step. Could we introduce some workaround in the meantime? Like emitting plain non-bundled commonjs modules without
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
Turns out... it looks like I already can output CommonJS modules and keep
You need to set
The only feature which isn't supported in that way is tree shaking, which brings me back to the original feature request.
It seems to me like Webpack is going to need functionality for compiling CommonJS and other formats to ES Modules, am I correct? I've been diving deep into this for the past few days. It seems like the whole world has traditionally been compiling from other formats to CommonJS. There is a popular babel plugin that does this. That problem seems to have been solved quite well by the community. But we need to go the other way, from CommonJS (or other formats) to ES Modules.
I'm not sure how much compilation/transpilation Webpack does itself, but that might be outside of its scope. Perhaps a Babel plugin would be the best choice here. Then the functionality could be leveraged by all libraries that need to go from CommonJS -> ES Modules. There is some prior art:
Basic Babel plugin for going from CommonJS -> ES Modules (basic, I've already run into a few blocking bugs, no community): https://www.npmjs.com/package/babel-plugin-transform-commonjs-es2015-modules
Advanced Rollup plugin for going from CommonJS -> ES Modules (seems very popular, most likely works very well, not very portable outside of Rollup. Might be easy to integrate within Webpack if Webpack has Rollup integration): https://github.com/rollup/rollup-plugin-commonjs
As I see it, this functionality should be created independent of Webpack and then incorporated as a dependency, through either a Bable plugin (most ideal), or perhaps a Rollup plugin (already implemented, might need to finagle).
Disclaimer, I'm not a heavy Webpack user nor in the Webpack community, these are just my thoughts as I've been trying to tackle the issue of CommonJS -> ES Modules
anybody give me an example, txs!!!
Since Webpack does not have the capability to build ES2015 module to export the vue-breadcrumb-privacy module , the library cannot be tree shaken when imported. As a result in src/scripts/switch-to/src/components/Body/Projects/ProjectLink.vue we need a dependency that is not needed for the part of the imported library. Issue introduced by 807fd75. Part of request #19247: Extract an internal lib for BreadcrumbPrivacy vue component  webpack/webpack#2933 Change-Id: Ibc8357150ac7bfe12e887baa811e281d86198792
We will start with very basic support, which has a few limitation:
But it would allow:
So this should cover basic needs for applications or some libraries that are consumed at runtime.
The next step would be to get rid of the first 3 limitations when the following conditions are met:
For other use cases (like bundling a library for consumption via bundler), there is another option we are considering:
No chunking and emitting processed modules as ESM instead.
Instead of joining the modules together into chunks webpack would emit the modules directly (converting them to esm, sometimes wrapping them in functions, module ID => path).
This allow the library to be tree-shaken. Since Webpack is not capable of building ES2015 module for libraries , it is replaced by Vite . The only inconvenient of this switch is that Vite does not have a build watch mode at the moment  so we simulate it using nodemon . Note that we still also deliver the lib as UMD because Jest needs it. Part of request #19287: Make internal libs "tree-shakeable"  webpack/webpack#2933  https://vitejs.dev  vitejs/vite#1434  https://nodemon.io/ Change-Id: I8341202dec6124c9704e630cbf348d5e02bb6746