support output.libraryTarget: 'module'

[donaldpipowitch]

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]

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]

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]

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]

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

[donaldpipowitch]

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]

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]

@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]

Would love to this implemented!

[HipsterZipster]

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

[yansern]

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

[itsdouges]

@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 :-)

[lastmjs]

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]

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]

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]

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

[laverdet]

Looks like import assertions are being stripped out from external modules. These are needed to import JSON files under nodejs v18.x.

import tlds from "tlds" assert { type: "json" };

Becomes:

import * as __WEBPACK_EXTERNAL_MODULE_tlds__ from "tlds";

To be honest I didn't troubleshoot this too much. I'm running Webpack v5.73.0 with a pretty in depth configuration that I'm migrating to module output. It's possible babel or someone else is stripping them before it gets to Webpack but I thought I would raise it here. I can work around it by bundling the small handful of JSON files.

[alexander-akait]

@laverdet sounds like a critical bug, can you open an issue?

[WalterWeidner]

I have followed the documentation, read through much of this issue, tried several of the solutions others have seen work but I still cannot get a library built with Webpack to be tree-shakable.

Currently this is all there is to that library configuration (also has sideEffects: false in the package.json):

import path from 'path';
import { fileURLToPath } from 'url';

const __filename = fileURLToPath(import.meta.url);
const __dirname = path.dirname(__filename);

export default {
	entry: path.resolve(__dirname, './src/index.js'),
	mode: 'production',
	module: {
		rules: [
			{
				include: path.resolve(__dirname, './src'),
				test: /\.(js|ts|tsx)$/,
				use: ['babel-loader'],
			},
		],
	},
	optimization: {
		minimize: false,
		mangleExports: false,
	},
	output: {
		filename: 'index.js',
		path: path.resolve(__dirname, './dist'),
		library: {
			type: 'module',
		},
		chunkFormat: 'module',
		module: true,
	},
	resolve: {
		extensions: ['.tsx', '.ts', '.js', '.jsx'],
	},
	experiments: {
		outputModule: true,
	},
	devtool: false,
	target: ['web', 'es2020'],
};

I've set up a repository with a both a Webpack app and a Vite app that consume test libraries built by most of the modern JS build tools (Babel, ESBuild, Vite, Webpack) and the Webpack app correctly treeshakes the exports from all of the libraries except for the one also built with Webpack. We see the same when importing the library built with Webpack into a Vite app.

I feel like I may be missing something obvious here but can't seem to get it to work with Webpack.

Note: Babel is configured to output ESM.

export default {
	presets: [['@babel/preset-env', { modules: false }]],
};

[alexander-akait]

@WalterWeidner Why you need webpack to build ESM library? I think better to keep source code in ESM in nowdays

[WalterWeidner]

@WalterWeidner Why you need webpack to build ESM library? I think better to keep source code in ESM in nowdays

In this case the main reason is to limit the API surface area. This way we don't have to worry as much about breaking applications because we simply re-arranged code or because someone was using an implementation detail when they shouldn't be (this library is only used internally).

[timbomckay]

@WalterWeidner Why you need webpack to build ESM library? I think better to keep source code in ESM in nowdays

There may be many reasons someone needs to build their source code to deliver their ESM library. Off the top of my head could be to deliver to JS code for Vue/React/Angular/etc components, compiled typescript, bundling/externalizing particular dependencies, and reducing potential conflicts with various configs. Compiling typescript with tsc might suffice for simple TS modules, but it gets more complicated with delivering a framework specific component library from Vue SFCs, React JSX, or Angular component files.

[cseas]

@WalterWeidner Why you need webpack to build ESM library? I think better to keep source code in ESM in nowdays

Libraries with source code in TypeScript need a build pipeline and simple tsc doesn't work for many use cases listed here. Besides, it'd be nice to be able to leverage the webpack ecosystem for plugins like ImageMinimizer while still delivering an ESM library the users can tree-shake.

Achieving any of these use-cases isn't impossible today but would get a lot easier with webpack.

[lorenzodallavecchia]

@WalterWeidner Why you need webpack to build ESM library? I think better to keep source code in ESM in nowadays

There is some consensus that consuming a library made of a single "Flat ESM" module (FESM) is more performant for downstream tools than consuming a library made up of tons of small ESM modules.

Angular strongly advocates using FESM, shipping all their packages with ESM bundles as a primary format and also advising developers to do the same for their libraries. Of course, the tooling used today requires additional post-processing via Rollup.

[WalterWeidner]

@WalterWeidner Why you need webpack to build ESM library? I think better to keep source code in ESM in nowdays

I am curious about why the library output configuration options exist in Webpack if you feel this way. Is it meant to accomplish something different? It was always my assumption that its purpose was for something like what I am trying to do.

[alexander-akait]

@WalterWeidner Yeah, I see your problem, library original was design for commonjs/umd/etc, when we don't have ESM, when we implement ESM library (with keep original tree and we have paln to do it), anyway can you create reproducible example and desribe the problem, I will look, thank you

[WalterWeidner]

@WalterWeidner Yeah, I see your problem, library original was design for commonjs/umd/etc, when we don't have ESM, when we implement ESM library (with keep original tree and we have paln to do it), anyway can you create reproducible example and desribe the problem, I will look, thank you

@alexander-akait pulling this repository and then running yarn && yarn build should output what I am seeing (the function shouldNotExist() and its console.log() should not be in the webpack app's bundle). The whole purpose of that repository is to help pinpoint the tree-shaking issues we were seeing in a very basic environment.

If that's not what you need I am happy to spin up something else to help get to root of the problem more efficiently.

[alexander-akait]

@WalterWeidner Yeah, I see your problem, we generate __webpack_require__.d, and that is prevent us for tree shaking, we should improve it for libraries

[WalterWeidner]

@WalterWeidner Yeah, I see your problem, we generate __webpack_require__.d, and that is prevent us for tree shaking, we should improve it for libraries

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]

Any updates? I want to use it for libraries, too