Skip to content
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

support output.libraryTarget: 'module' #2933

Open
donaldpipowitch opened this issue Aug 30, 2016 · 71 comments
Open

support output.libraryTarget: 'module' #2933

donaldpipowitch opened this issue Aug 30, 2016 · 71 comments

Comments

@donaldpipowitch
Copy link

@donaldpipowitch donaldpipowitch commented Aug 30, 2016

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.

@TheLarkInn
Copy link
Member

@TheLarkInn TheLarkInn commented 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
Copy link
Author

@donaldpipowitch donaldpipowitch commented 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
Copy link
Member

@TheLarkInn TheLarkInn commented Oct 13, 2016

For a feature like this we should write up the design for the feature. Questions I think should be answerered first:

  • if someone uses CJS/AMD/non-esm dependencies in their library, how does webpack convert this into esm modules?
  • Should externals be leveraged for lib dependencies?
@TheLarkInn
Copy link
Member

@TheLarkInn TheLarkInn commented Oct 13, 2016

Once we have the behavior designed then you can go straight into adding the test cases.

@donaldpipowitch
Copy link
Author

@donaldpipowitch donaldpipowitch commented 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
Copy link
Author

@donaldpipowitch donaldpipowitch commented 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 like new 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
Copy link

@nadavsinai nadavsinai commented 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...

@animamundi
Copy link

@animamundi animamundi commented May 10, 2017

Would love to this implemented!

@HipsterZipster
Copy link

@HipsterZipster HipsterZipster commented Sep 27, 2017

Have there been any updates to this issue in the past year? Is it being tracked elsewhere?

@yansern
Copy link

@yansern yansern commented Sep 28, 2017

Having to learn both webpack and rollup is no fun! Would love to have this implemented in webpack.

@madou
Copy link

@madou madou commented Oct 15, 2017

@sokra @TheLarkInn hey guys. if one (me) wanted to start looking at how to resolve this issue would you have any suggestions? any ideas of how much would need to change to support this?

i'd be keen to lend some time if you could put me on the right path :-)

saki7 added a commit to saki7/nagato that referenced this issue Oct 29, 2017
…ck's tree shaking.

This is currently *not* supported by Webpack (see webpack/webpack#1979 (comment) and webpack/webpack#2933 for rationale).

We workaround this by exposing our babel config to the wild (i.e. js/nagato/babel-options.js). This way we can give full controls for both bundling (i.e. 'tree shaking' in Webpack) and module building (i.e. 'transpiling') to the library users (I hope).

We just can't enforce our users to use some huge-sized arbitrary bundle.

Users with ES2015+ (or whatever) environment shall `require()` this config file inside their 'webpack.config.js', and use it as a hash object for the `babel-loader`'s `option: ` option. This could be achieved by looking into the `module: ` option in `package.json`; which (I believe) is the default behavior for Webpack when you use the native `import Something from 'other-external-library'` syntax.

If this is not desirable, use the fully-transpiled .js file inside our distributed npm package. This could be achieved by referring to the old-school `"main"` value inside the package.json.

Disclaimer:
By using this method we abandon Webpack-specific aggresive transpilation features for our entire library. This means we can't use Webpack-specific custom `import`s (i.e. importing non-JavaScript files like images (.png, .jpg, etc.) inside our library (.js)).

Additional notes:
This issue described in the disclaimer section can be workarounded by specifying your library-specific `npm run build` action inside the `prepare` section of package.json.
@lastmjs
Copy link

@lastmjs lastmjs commented Mar 19, 2018

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

@ooflorent
Copy link
Member

@ooflorent ooflorent commented Mar 19, 2018

I think webpack must wait until CJS / ESM interop has been standarized into node. There are plenty projects that made opinionated choices about it and it could break the existing codebases if things got spec-ed differently.

@moroine
Copy link

@moroine moroine commented Mar 20, 2018

Hello,

I have a library fully written in Es6, and due to webpack limitations I'm not able to propose my library in es6 module that would enable treeshaking feature on for clients

@ooflorent
Copy link
Member

@ooflorent ooflorent commented Mar 20, 2018

@moroine For library, I would recommend using rollup. And webpack for applications.
Rich Harris (rollup's creator) wrote about it: Webpack and Rollup: the same but different.

@sokra
Copy link
Member

@sokra sokra commented Oct 24, 2020

This will be one of the next features we will work on.

@yoyo837
Copy link

@yoyo837 yoyo837 commented Dec 1, 2020

So, webpack@5.9.0 support ESModule now? This issue can be close safely?

@alexander-akait
Copy link
Member

@alexander-akait alexander-akait commented Dec 1, 2020

For libraries - no

@GMartigny
Copy link

@GMartigny GMartigny commented Dec 16, 2020

Hello,

What tasks are still pending to resolve this ? I would love to help on this, but I don't know what's left to do.

@779102260
Copy link

@779102260 779102260 commented Jan 13, 2021

experiments.outputModule not work,here is a codesandbox demo:

https://codesandbox.io/s/outputmodule-test-uog4c?file=/src/main.js

output nothing~

anybody give me an example, txs!!!

@linxiaowu66
Copy link

@linxiaowu66 linxiaowu66 commented Jan 13, 2021

So, webpack@5.9.0 support ESModule now? This issue can be close safely?

@mrmckeb
Copy link

@mrmckeb mrmckeb commented Jan 13, 2021

No, sorry @linxiaowu66 - see this issue:
#8895 (comment)

LeSuisse added a commit to Enalean/tuleap that referenced this issue Feb 2, 2021
Since Webpack does not have the capability to build ES2015 module to
export the vue-breadcrumb-privacy module [0], 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

[0] webpack/webpack#2933

Change-Id: Ibc8357150ac7bfe12e887baa811e281d86198792
@sokra
Copy link
Member

@sokra sokra commented Feb 5, 2021

In progress...

We will start with very basic support, which has a few limitation:

  • No circular dependencies with externals
  • A little bit of not really needed runtime
  • No live-bindings of exports
  • Not statically analyse-able bundles (no nested bundling)
  • When top-level-await is used, it must also be supported by the target environment
  • No runtime chunk
  • All modules are converted into strict mode (maybe there will be a warning which lists non-strict modules)

But it would allow:

  • ESM exports from entrypoint
  • externals that are ESM too
  • chunk loading via native import()
  • Initial splitChunks loading via ESM import
  • Module WebWorkers
  • Module Federation remote loading via ESM

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:

  • entrypoint is an ESM
  • exports are not reexported from modules that can't be concatenated with the entrypoint (like CJS, splitChunks)

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).


target: "node" should generate import for built-in Node.js modules (like process/fs/etc)

LeSuisse added a commit to Enalean/tuleap that referenced this issue Feb 12, 2021
This allow the library to be tree-shaken.

Since Webpack is not capable of building ES2015 module for libraries [0],
it is replaced by Vite [1]. The only inconvenient of this switch is that
Vite does not have a build watch mode at the moment [2] so we simulate
it using nodemon [3].

Note that we still also deliver the lib as UMD because Jest needs it.

Part of request #19287: Make internal libs "tree-shakeable"

[0] webpack/webpack#2933
[1] https://vitejs.dev
[2] vitejs/vite#1434
[3] https://nodemon.io/

Change-Id: I8341202dec6124c9704e630cbf348d5e02bb6746
@huy-ta huy-ta mentioned this issue Mar 22, 2021
1 of 1 task complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Linked pull requests

Successfully merging a pull request may close this issue.

None yet