A bundler for javascript and friends. Packs many modules into a few bundled assets. Code Splitting allows for loading parts of the application on demand. Through "loaders", modules can be CommonJs, AMD, ES6 modules, CSS, Images, JSON, Coffeescript, LESS, ... and your custom stuff.
MIT License
61881
1530
8508

Bug report

What is the current behavior?

in runtime~main.js, it causes a error named A default export must be at the top level of a file or module declaration.

image

const path = require("path");
const Html = require("html-webpack-plugin");

module.exports = {
  entry: path.join(__dirname, "./src/app.js"),
  output: {
    path: path.join(__dirname, "dist"),
    clean: true,
    chunkFormat: "module",
  },
  target: "es2021",
  mode: "development",
  devtool: false,
  optimization: {
    runtimeChunk: true,
  },
  plugins: [
    new Html({
      scriptLoading: "module",
    }),
  ],
};

If the current behavior is a bug, please provide the steps to reproduce.

What is the expected behavior?

Other relevant information:
webpack version: "^5.74.0",
Node.js version: v14.19.3
Operating System: macOS
Additional tools:

Bug report

What is the current behavior?

webpack emits extra message about compilation on startup with Yarn 2:

Screenshot

Screenshot_621

If the current behavior is a bug, please provide the steps to reproduce.

Reproduction examples: with file-loader

We have: webpack in basic configuration, Yarn 2 and some webpack loader.

  1. Loader should be resolved by require.resolve
  2. You should import file which should be handled by this loader
  3. Then you can see that webpack emits extra message about compilation

Note that if you remove require.resolve for loader issue will disappear.

webpack.config.js

module.exports = {
  module: {
    rules: [
      {
        loader: require.resolve('file-loader'),
        exclude: /\.js$/
      }
    ]
  }
};

src/index.js

const svg = require('./icon.svg');

console.log('svg url', svg);

src/icon.svg

What is the expected behavior?

The compilation should only trigger once.

Other relevant information:

node -v - v14.15.4
yarn -v - 2.4.0

"file-loader": "6.2.0",
"webpack": "5.17.0",
"webpack-cli": "4.4.0"

I am getting a strange error when generating my code artifacts using webpack. But when I went to look for the "missing" modules, it is there.

Example

ERROR in ../../../node_modules/@babel/runtime-corejs3/regenerator/index.js 3:14-54
Module not found: Error: Can't resolve '../helpers/regeneratorRuntime' in 'C:\Temp10\Ahab\node_modules@babel\runtime-corejs3\regenerator'
@ ./src/lib/dependent-option-sets.ts 2:0-69 105:42-66 108:11-35

image

image

Bug report

What is the current behavior?

The newly-introduced dependOn feature to be released with Webpack 5 seems to have non-deterministic behaviour when exporting UMD modules and using a require-based (i.e. AMD) loader.

What appears to be the fundamental issue is that an import of a module that depends on another does not result in a proper import of the dependent module; e.g. if Module A depends on Module B, then a simple define([ModuleA], function(ModuleA) { ... }) does not seem to kick off a proper require of Module B.

If the current behavior is a bug, please provide the steps to reproduce.

webpack.config.js snippet:

entry: {
  ModuleC: `${process.cwd()}/ModuleC`,
  ModuleB: {
    import: `${process.cwd()}/ModuleB`,
    dependOn: 'ModuleC',
  },
  ModuleA: {
    import: `${process.cwd()}/ModuleA`,
    dependOn: ['ModuleB', 'ModuleC'],
  }
},
output: {
  path: `${process.cwd()}/dist`,
  filename: '[name].js',
  library: 'modules',
  libraryTarget: 'umd'
}

Module A:

import ModuleB from './ModuleB';
import ModuleC from './ModuleC';

const ModuleA = function() {
  console.log('A');
  ModuleB();
  ModuleC();
};

export default ModuleA;

Module B:

import ModuleC from './ModuleC';

const ModuleB = function() {
  console.log('B');
  ModuleC();
};

export default ModuleB;

Module C:

const ModuleC = function() {
  console.log('C');
};

export default ModuleC;

Bundling these with webpack results in strange behaviour - I have created a couple of scenarios in my minimal test github repo to demonstrate this:

  1. In basepage-1.html, I test out the simpler case of simply loading ModuleA (in main-1.js) in the browser. This doesn't ever work (breakpoints indicate that require simply returns a number like 1 or 2). The network indicates that no attempt is made to load ModuleB or ModuleC.
  2. In basepage-2.html, I test out the more complex case of loading all of the Modules C through A (in that order, in main-2.js). Continual refreshes of the browser sometimes allows different modules to work, but the actual output of the first ModuleX.default() call can change depending on what I assume to be the result of a race condition of the module loads.

What is the expected behavior?

  1. In basepage-1.html (i.e. main-1.js), I expect ModuleA to successfully load ModuleB and ModuleC, resulting in an output of:
A    // Here begins output of ModuleA
B
C
C
  1. In basepage-2.html (i.e. main-2.js), I expect all three modules to load successfully, and the calls to the functions resulting in an output of:
C    // Here begins output of ModuleC
B    // Here begins output of ModuleB
C
A    // Here begins output of ModuleA
B
C
C

If I remove the dependOn field from my webpack config and load the three non-dependent chunks as regular entry points, there is no race condition and all modules load properly and provide the proper output.

Other relevant information:
webpack version: 5.0.0-beta.14
Node.js version: 10.18.1
Operating System: macOS Mojave 10.14.6
Additional tools:

  1. Any recent-ish Chrome browser version
  2. RequireJS (found here: https://requirejs.org/docs/release/2.3.6/minified/require.js)

Bug report

What is the current behavior?

Bundling with libraryTarget module, new Worker with options type classic will be rewritten from:

const myWorker = new Worker(new URL("worker.js", import.meta.url), {
  type: "classic",
});

to:

const myWorker = new Worker(new URL(/* worker import */ __webpack_require__.p + __webpack_require__.u(695), __webpack_require__.b), {
  type: "module",
});

That's an issue when the imported worker contains importScripts as loading it as module will throw:
Uncaught TypeError: Failed to execute 'importScripts' on 'WorkerGlobalScope': Module scripts don't support importScripts().

If the current behavior is a bug, please provide the steps to reproduce.

Gist with repro case: https://gist.github.com/dmnsgn/1b6b464a6c6aa2ed4d4c1d2a18042e02

git clone https://gist.github.com/dmnsgn/1b6b464a6c6aa2ed4d4c1d2a18042e02
cd 1b6b464a6c6aa2ed4d4c1d2a18042e02/
npm i
npm run build

To see the importScripts error in a browser (otherwise just look at the output dist/bundle.js):

npm serve

What is the expected behavior?

It should keep type classic even when setting a libraryTarget to module.

Other relevant information:
webpack version: 5.64.3
Node.js version: 17.1
Operating System: MacOS
Additional tools:

Bug report

What is the current behavior?

Webpack randomly fails to bunle which causes Uncaught SyntaxError: Unexpected token '}' error message and broken code:

It seems like it adds the following segment twice, which causes the problem:

/******/ })()
;

image

If the current behavior is a bug, please provide the steps to reproduce.

The issue occurs randomly, the same codebase might fail without any code change.
cross-env NODE_ENV=production webpack --config ./webpack.config.js is being used here.

What is the expected behavior?

The build shouldn't fail randomly, the last 2 duplicate lines shouldn't be added at the end of the file.

Other relevant information:
webpack version: 5.72.0 (this started happening after we've upgraded Webpack from v4 to v5)
Node.js version: 14.0
Operating System: Ubuntu 20.04
Additional tools: gulp, tailwind v1.2, react v16.8

Feature request

What is the expected behavior?

When building an ESM build in Webpack, free __filename and __dirname references in CommonJS files should be supported.

What is motivation or use case for adding/changing the behavior?

See eg vercel/ncc#749 for an ncc bug here.

How should this be implemented in your opinion?

The referencing could do relative path logic or not. That shoudl likely be configurable. In the base case for CommonJS the __filename value would be the output file __filename value which seemed to work in some scenarios.

One could just define CJS free __filename references as fileURLToPath(import.meta.url) in the Webpack bundle.

Are you willing to work on this yourself?
no

Bug report

What is the current behavior?

I am using vue-cli, which uses Webpack in the background to build a vue3 library with multiple entries.
Shared vendor modules are output into separate chunks.
This works great in development, but I get errors related to dynamic chunk loading in random production builds.
I sometimes end up having to run the build process several times (without changing anything) before getting a working one.
I can't quite figure out what's causing this, and have tried moving to a single entry setup, but this didn't change anything.

The errors are also not always the same, and occur even though the chunk seems to be correctly loaded.
Here are some examples of the errors that occur:

  • Uncaught (in promise) TypeError: e[r] is undefined
  • ChunkLoadError: Loading chunk 'xx' failed (although I do see the chunk loading in the browser's network console)

I noticed that when the errors occur vendor chunks seem to not be minified, unlike in working builds.

If the current behavior is a bug, please provide the steps to reproduce.

Since the errors occur on random builds, I can't quite create a minimal reproduction example.

What is the expected behavior?

I expect production builds to be consistent and to have dynamic chunks not produce errors when loaded.

Other relevant information:
webpack version: 5.74.0
Node.js version: 16.17.0
Operating System: Debian 10 under WSL
Additional tools: vue-cli, CKEditorWebpackPlugin

Such cases seem to have been experienced by others using webpack (https://stackoverflow.com/questions/61090881/webpack-laravel-mix-chunk-error-typeerror-er-is-undefined, https://stackoverflow.com/questions/53704950/webpack-code-splitting-loading-chunk-failed-error-wrong-file-path), but are usually due to network/caching issues, which is not my case as I disabled caching in my browser all together and see the chunks loading fine in the network console.

This might be an issue in the Terser plugin, but I don't see any warning or errors when building.
Is there maybe a way to monitor the build process in a more verbose way that what is output by default ?

Bug report

What is the current behavior?
One of our packages has version 'dev' set in package.json as it is internal not released yet package.

....
"dependencies": {
    "{PACKAGE_NAME}": "dev",
}
....

When I try to configure ModeFederationPlugin for our main app I configure shared modules as follows:

const packageJson = require('../package.json');

const packageName = packageJson.name;
const packageDeps = packageJson.dependencies;

new ModuleFederationPlugin({
   ....
    shared: {
      ...packageDeps,
      react: {
        singleton: true,
        eager: true,
        requiredVersion: packageDeps.react,
      },
      'react-dom': {
        singleton: true,
        eager: true,
        requiredVersion: packageDeps['react-dom'],
      },
    },
    ....
  }),

When I run webpack it gives me next error:

ERROR in resolving fallback for shared module ($PACKAGE_NAME}
Module not found: Error: Can't resolve 'dev' in '{PATH_TO_FILE_USING_PACKAGE}'

If the current behavior is a bug, please provide the steps to reproduce.

  1. Add package with version different from semantic versioning standard to dependencies of the project
  2. Try to add ModuleFederationPlugin to the webpack config of the app with the following config:
const packageJson = require('../package.json');

const packageName = packageJson.name;
const packageDeps = packageJson.dependencies;

new ModuleFederationPlugin({
    name: packageName,
    remotes: {},
    shared: {
      ...packageDeps,
      angular: {
        singleton: true,
        eager: true,
        requiredVersion: packageDeps.angular,
      },
      react: {
        singleton: true,
        eager: true,
        requiredVersion: packageDeps.react,
      },
      'react-dom': {
        singleton: true,
        eager: true,
        requiredVersion: packageDeps['react-dom'],
      },
    },
  }),
  1. Run webpack and see the errors in the console

What is the expected behavior?
I assume that if webpack can resolve node_modules with non-semantic versioning then ConsumeSharedPlugin should also be able to

If any additional info is needed for me, please let me know

Other relevant information:
webpack version: 5.24.4
Node.js version: v14.15.0
Operating System: macOS Catalina Version 10.15.7
Additional tools:

using webpack ^4.12.0 i've run into a bug with DefinePlugin creating unexpected token errors. in my webpack config i am injecting global values like this:

new webpack.DefinePlugin({
  API_ENDPOINT: 'https://api.test.company.io',
}),

but when running a webpack build i get this error (everything still transpiles, but if i do a find-all in the generated code the value of the global was never injected):

{ SyntaxError: Unexpected token (1:6)
at Parser.pp$4.raise (/<node_modules>/acorn/dist/acorn.js:2757:13)
at Parser.pp.unexpected (/<node_modules>/acorn/dist/acorn.js:647:8)
at Parser.pp.expect (/<node_modules>/acorn/dist/acorn.js:641:26)
at Parser.pp$3.parseParenAndDistinguishExpression (/<node_modules>/acorn/dist/acorn.js:2228:38)
at Parser.pp$3.parseExprAtom (/<node_modules>/acorn/dist/acorn.js:2163:41)
at Parser.parseExprAtom (/<node_modules>/acorn-dynamic-import/lib/inject.js:60:31)
at Parser.pp$3.parseExprSubscripts (/<node_modules>/acorn/dist/acorn.js:2047:19)
at Parser.pp$3.parseMaybeUnary (/<node_modules>/acorn/dist/acorn.js:2024:17)
at Parser.pp$3.parseExprOps (/<node_modules>/acorn/dist/acorn.js:1966:19)
at Parser.pp$3.parseMaybeConditional (/<node_modules>/acorn/dist/acorn.js:1949:19)
at Parser.pp$3.parseMaybeAssign (/<node_modules>/acorn/dist/acorn.js:1925:19)
at Parser.pp$3.parseExpression (/<node_modules>/acorn/dist/acorn.js:1896:19)
at Parser.pp$1.parseStatement (/<node_modules>/acorn/dist/acorn.js:815:45)
at Parser.parseStatement (/<node_modules>/acorn-dynamic-import/lib/inject.js:47:31)
at Parser.pp$1.parseTopLevel (/<node_modules>/acorn/dist/acorn.js:706:23)
at Parser.parse (/<node_modules>/acorn/dist/acorn.js:551:15)
at Object.parse (/<node_modules>/acorn/dist/acorn.js:5288:37)
at Function.parse (/<node_modules>/webpack/lib/Parser.js:2229:16)
at Parser.evaluate (/<node_modules>/webpack/lib/Parser.js:2132:22)
at parser.hooks.evaluateIdentifier.for.tap.expr (/<node_modules>/webpack/lib/DefinePlugin.js:180:29)
...

the stack trace keeps going, but that last line was what finally unlocked this issue for me and led me to this thread on visionmedia's debug repo. where the suggested solution to wrap values in JSON.stringify actually fixed my issue.

so, my next guess was that special characters were killing the DefinePlugin constructor. i tried running builds without special characters in the DefinePlugin constructor, and then slowly reintroduced characters into its diet until it died:

// works with no special characters
new webpack.DefinePlugin({
  API_ENDPOINT: 'httpsapitestcompanyio',
}),

// works when introducing the period character
new webpack.DefinePlugin({
    API_ENDPOINT: 'httpsapi.test.company.io',
}),

// dies when introducing colon
new webpack.DefinePlugin({
    API_ENDPOINT: 'https:api.test.company.io',
}),

// works when introducing one slash
new webpack.DefinePlugin({
    API_ENDPOINT: 'https/api.test.company.io',
}),

// dies when introducing two slashes
new webpack.DefinePlugin({
    API_ENDPOINT: 'https//api.test.company.io',
}),

// dies with both colon and slashes
new webpack.DefinePlugin({
    API_ENDPOINT: 'https://api.test.company.io',
}),

wrapping the URL container special characters in a JSON.stringify call is a valid workaround for the bug:

new webpack.DefinePlugin({
    API_ENDPOINT: JSON.stringify('https://api.test.company.io'),
}),

the other (maddening, table-flip inducing, completely nonsensical) workaround is to lowercase the name of the global var:

new webpack.DefinePlugin({
  api_endpoint: 'https://api.test.company.io'), // this works...
}),

🤷‍♂️

Feature request

What is the expected behavior?
When I add the Configuration type to the Webpack config in a TypeScript file, and add configuration for webpack-dev-server, it throws an error. For example:

import { Configuration } from "webpack";

const config: Configuration = {
  mode: development,
  // ...
  devServer: {  // throws an error as there is no interface for devServer
    port: 3000
  }
};

The Configuration interface therefore, should have a property for devServer.

What is motivation or use case for adding/changing the behavior?
This should be added because if you want to use TypeScript for the Webpack config in a frontend project, and add configuration for webpack-dev-server, it should not throw an error.

How should this be implemented in your opinion?
An interface for devServer should be added to the Configuration interface.

Are you willing to work on this yourself?
yes

Bug report

What is the current behavior?
If a federated import exists under a specific entrypoint that is not yet loaded, and webpack uses runtimeChunk: single - the initialization will fail.

Initialization of sharing external failed: Error: Cannot find module 'checkout@http://localhost:3000/_next/static/ssr/remoteEntry.js'

If the current behavior is a bug, please provide the steps to reproduce.

Import different remotes under different entrypoints that are not loaded on the page at the same time.
For example, next.js - pages are entrypoints.

When booting the application, the webpack runtime will attempt to initialize the external, but crashes because the module containing the containerReference module is not yet loaded/on the page.

/******/ 				case "default": {
/******/ 					register("next/dynamic", "12.3.0", function() { return __webpack_require__.e("node_modules_next_dynamic_js").then(function() { return function() { return __webpack_require__(/*! ../node_modules/next/dynamic.js */ "../node_modules/next/dynamic.js"); }; }); });
/******/ 					initExternal("webpack/container/reference/home"); // initialized correctly
/******/ 					initExternal("webpack/container/reference/shop"); // moduleID doesnt exist yet, entrypoint not loaded
/******/ 					initExternal("webpack/container/reference/checkout"); // module id doesnt exist yet, entrypoint not loaded
/******/ 				}

What is the expected behavior?

ContainerReferences should be hoisted to initial chunk so that webpack runtime can properly initialize all remotes. This should only happen when runtimeChunk: single is set

Other relevant information:
webpack version: 5.64.4
Node.js version: 16
Operating System: MacOS
Additional tools: Next.js, module-federation/nextjs-mf plugin

Continuation of #8636 (closed because of inactivity)
Related: #9393 (closed because of inactivity)

versions

webpack 5.54.0
webpack-cli 4.8.0

Feature request

// webpack.config.js
const path = require('path');

/** @type {import('webpack').Configuration} */
module.exports = {
  mode: 'none',
  entry: './src/entry.js',

  externals: [
    ({request}, cb) => request.startsWith('extpack') ? cb(null, 'extpack', 'commonjs') : cb(),
  ],

  output: {
    path: path.resolve(__dirname, "dist"),
    filename: "[name].js",
  },
};
// src/entry.js
console.log(require('extpack'));
console.log(require.resolve('extpack/some/file.txt'))

It produces following dist/main.js

// ...
/* 1 */
/***/ ((module) => {

"use strict";
module.exports = require("extpack");

/***/ })
// ...
console.log(__webpack_require__(1));
console.log(/*require.resolve*/(1))
// ...

What is the expected behavior?

With some options to produce following.

// ...
console.log(__webpack_require__(1));
// OR
// console.log(require('extpack'))
console.log(require.resolve('extpack/some/file.txt'))
// ...

What is motivation or use case for adding/changing the behavior?

Entrust all resolutions about some packages to node.
It may seem no need to use webpack, but I'd like to use this combined with vercel/next.js.

Also it seems no matter to bundle, but some packages are using node native binaries (nodejs/node-gyp) like require('./build/some.node') or require.resolve('./build/some.node'). They should be resolved in unbundled environment. *.node can't be run only with itself, so I can't use type: 'asset/resource' for this. It can be seen as *.node is out of webpack resolution/depedants detection.

How should this be implemented in your opinion?

  • New import type for externals, like "commonjs-require-resolve"
  • And add new property like originalType in context arg to know whether it is require.resolve'd in original source.
// ...
externals: [
  ({request, originalType}, cb) => request.startsWith('extpack') ? cb(null, 'extpack', originalType === 'commonjs-require-resolve' ? originalType : 'commonjs') : cb(),
],
// ...

I'm not passing originalType itself because to correctly transform import ... for example.

Some type of imports are not used as output, so they should be something like "unknown", null, "input-import", etc...

EDIT:

  1. or add new types ("native-commonjs").
// ...
externals: [
  ({request}, cb) => request.startsWith('extpack') ? cb(null, 'extpack', 'native-commonjs') : cb(),
],
// ...

Are you willing to work on this yourself?
a little but I'm sorry I can't work it on soon. It may be after Dec 2021

Feature request

It happens sometimes that invalid paths are entered (via path.resolve) in rule.include. But webpack silently "accepts" this and the loader does nothing. But the user is confused why nothing has changed. Debugging of this simple but silent error is not that easy.

What is the expected behavior?

Invalid paths in rule.include (and probably also exclude) like for example path.resolve(__dirname, 'src', 'node_modules'), should throw a warning / error so the user knows that there is something not correct.

What is motivation or use case for adding/changing the behavior?

Better DX and feedback from webpack, easier debugging.

How should this be implemented in your opinion?

Warning and optional setting to bail on invalid paths.

Are you willing to work on this yourself?
no (not much time anymore)

Bug report

What is the current behavior?
Setting experiments.outputModule: true provokes an error in the compiled bundle in the browser, when using a (single) runtime chunk. The error occurs in the main file main.9557a1f0.js, on the very last line of the file:

Uncaught TypeError: (intermediate value).X is not a function

The last few lines in main.9557a1f0.js, error happens on the last line:

// load runtime
import __webpack_require__ from "./runtime.45fa48bb.js";
import * as __webpack_self_exports__ from "./main.9557a1f0.js";
__webpack_require__.C(__webpack_self_exports__);
var __webpack_exec__ = (moduleId) => (__webpack_require__(__webpack_require__.s = moduleId))
var __webpack_exports__ = __webpack_require__.X(0, [532,736], () => (__webpack_exec__(5762)));

runtime.45fa48bb.js looks like this:

/******/ "use strict";
/******/ var __webpack_modules__ = ({});
/************************************************************************/
/******/ // The module cache
/******/ var __webpack_module_cache__ = {};
/******/ 
/******/ // The require function
/******/ function __webpack_require__(moduleId) {
/******/ 	// Check if module is in cache
/******/ 	var cachedModule = __webpack_module_cache__[moduleId];
/******/ 	if (cachedModule !== undefined) {
/******/ 		return cachedModule.exports;
/******/ 	}
/******/ 	// Create a new module (and put it into the cache)
/******/ 	var module = __webpack_module_cache__[moduleId] = {
/******/ 		// no module.id needed
/******/ 		// no module.loaded needed
/******/ 		exports: {}
/******/ 	};
/******/ 
/******/ 	// Execute the module function
/******/ 	__webpack_modules__[moduleId].call(module.exports, module, module.exports, __webpack_require__);
/******/ 
/******/ 	// Return the exports of the module
/******/ 	return module.exports;
/******/ }
/******/ 
/******/ // expose the modules object (__webpack_modules__)
/******/ __webpack_require__.m = __webpack_modules__;
/******/ 
/************************************************************************/
/******/ /* webpack/runtime/compat get default export */
/******/ (() => {
/******/ 	// getDefaultExport function for compatibility with non-harmony modules
/******/ 	__webpack_require__.n = (module) => {
/******/ 		var getter = module && module.__esModule ?
/******/ 			() => (module['default']) :
/******/ 			() => (module);
/******/ 		__webpack_require__.d(getter, { a: getter });
/******/ 		return getter;
/******/ 	};
/******/ })();
/******/ 
/******/ /* webpack/runtime/create fake namespace object */
/******/ (() => {
/******/ 	var getProto = Object.getPrototypeOf ? (obj) => (Object.getPrototypeOf(obj)) : (obj) => (obj.__proto__);
/******/ 	var leafPrototypes;
/******/ 	// create a fake namespace object
/******/ 	// mode & 1: value is a module id, require it
/******/ 	// mode & 2: merge all properties of value into the ns
/******/ 	// mode & 4: return value when already ns object
/******/ 	// mode & 16: return value when it's Promise-like
/******/ 	// mode & 8|1: behave like require
/******/ 	__webpack_require__.t = function(value, mode) {
/******/ 		if(mode & 1) value = this(value);
/******/ 		if(mode & 8) return value;
/******/ 		if(typeof value === 'object' && value) {
/******/ 			if((mode & 4) && value.__esModule) return value;
/******/ 			if((mode & 16) && typeof value.then === 'function') return value;
/******/ 		}
/******/ 		var ns = Object.create(null);
/******/ 		__webpack_require__.r(ns);
/******/ 		var def = {};
/******/ 		leafPrototypes = leafPrototypes || [null, getProto({}), getProto([]), getProto(getProto)];
/******/ 		for(var current = mode & 2 && value; typeof current == 'object' && !~leafPrototypes.indexOf(current); current = getProto(current)) {
/******/ 			Object.getOwnPropertyNames(current).forEach((key) => (def[key] = () => (value[key])));
/******/ 		}
/******/ 		def['default'] = () => (value);
/******/ 		__webpack_require__.d(ns, def);
/******/ 		return ns;
/******/ 	};
/******/ })();
/******/ 
/******/ /* webpack/runtime/define property getters */
/******/ (() => {
/******/ 	// define getter functions for harmony exports
/******/ 	__webpack_require__.d = (exports, definition) => {
/******/ 		for(var key in definition) {
/******/ 			if(__webpack_require__.o(definition, key) && !__webpack_require__.o(exports, key)) {
/******/ 				Object.defineProperty(exports, key, { enumerable: true, get: definition[key] });
/******/ 			}
/******/ 		}
/******/ 	};
/******/ })();
/******/ 
/******/ /* webpack/runtime/ensure chunk */
/******/ (() => {
/******/ 	__webpack_require__.f = {};
/******/ 	// This file contains only the entry chunk.
/******/ 	// The chunk loading function for additional chunks
/******/ 	__webpack_require__.e = (chunkId) => {
/******/ 		return Promise.all(Object.keys(__webpack_require__.f).reduce((promises, key) => {
/******/ 			__webpack_require__.f[key](chunkId, promises);
/******/ 			return promises;
/******/ 		}, []));
/******/ 	};
/******/ })();
/******/ 
/******/ /* webpack/runtime/get javascript chunk filename */
/******/ (() => {
/******/ 	// This function allow to reference async chunks
/******/ 	__webpack_require__.u = (chunkId) => {
/******/ 		// return url for filenames based on template
/******/ 		return "chunks/" + chunkId + "." + {"62":"4d22a6c6","67":"eb5bd192","76":"a053f510","101":"11f763f3","154":"4ed28fbc","164":"58123216","252":"689b50e8","328":"39fece55","357":"3dcc8e36","364":"00dedba0","389":"a8523a16","414":"e59e9e99","458":"37991620","470":"aba0e8ed","538":"6f777776","615":"414e5680","694":"53e67fa9","708":"b4af9267","777":"1c04f591","800":"cc3bed2e","805":"02503685","806":"c545008d","842":"35ac0e89","930":"d9316a87","968":"247135fd","970":"60833f54","991":"64dd4b9c"}[chunkId] + ".js";
/******/ 	};
/******/ })();
/******/ 
/******/ /* webpack/runtime/get mini-css chunk filename */
/******/ (() => {
/******/ 	// This function allow to reference all chunks
/******/ 	__webpack_require__.miniCssF = (chunkId) => {
/******/ 		// return url for filenames based on template
/******/ 		return "" + "styles" + "." + "c71fa8d7" + ".css";
/******/ 	};
/******/ })();
/******/ 
/******/ /* webpack/runtime/global */
/******/ (() => {
/******/ 	__webpack_require__.g = (function() {
/******/ 		if (typeof globalThis === 'object') return globalThis;
/******/ 		try {
/******/ 			return this || new Function('return this')();
/******/ 		} catch (e) {
/******/ 			if (typeof window === 'object') return window;
/******/ 		}
/******/ 	})();
/******/ })();
/******/ 
/******/ /* webpack/runtime/hasOwnProperty shorthand */
/******/ (() => {
/******/ 	__webpack_require__.o = (obj, prop) => (Object.prototype.hasOwnProperty.call(obj, prop))
/******/ })();
/******/ 
/******/ /* webpack/runtime/make namespace object */
/******/ (() => {
/******/ 	// define __esModule on exports
/******/ 	__webpack_require__.r = (exports) => {
/******/ 		if(typeof Symbol !== 'undefined' && Symbol.toStringTag) {
/******/ 			Object.defineProperty(exports, Symbol.toStringTag, { value: 'Module' });
/******/ 		}
/******/ 		Object.defineProperty(exports, '__esModule', { value: true });
/******/ 	};
/******/ })();
/******/ 
/******/ /* webpack/runtime/publicPath */
/******/ (() => {
/******/ 	__webpack_require__.p = "/static/";
/******/ })();
/******/ 
/******/ /* webpack/runtime/export webpack runtime */
/******/ export default __webpack_require__;
/******/ 
/******/ /* webpack/runtime/import chunk loading */
/******/ (() => {
/******/ 	// no baseURI
/******/ 	
/******/ 	// object to store loaded and loading chunks
/******/ 	// undefined = chunk not loaded, null = chunk preloaded/prefetched
/******/ 	// [resolve, reject, Promise] = chunk loading, 0 = chunk loaded
/******/ 	var installedChunks = {
/******/ 		666: 0,
/******/ 		532: 0
/******/ 	};
/******/ 	
/******/ 	var installChunk = (data) => {
/******/ 		var {ids, modules, runtime} = data;
/******/ 		// add "modules" to the modules object,
/******/ 		// then flag all "ids" as loaded and fire callback
/******/ 		var moduleId, chunkId, i = 0;
/******/ 		for(moduleId in modules) {
/******/ 			if(__webpack_require__.o(modules, moduleId)) {
/******/ 				__webpack_require__.m[moduleId] = modules[moduleId];
/******/ 			}
/******/ 		}
/******/ 		if(runtime) runtime(__webpack_require__);
/******/ 		for(;i < ids.length; i++) {
/******/ 			chunkId = ids[i];
/******/ 			if(__webpack_require__.o(installedChunks, chunkId) && installedChunks[chunkId]) {
/******/ 				installedChunks[chunkId][0]();
/******/ 			}
/******/ 			installedChunks[ids[i]] = 0;
/******/ 		}
/******/ 	
/******/ 	}
/******/ 	
/******/ 	__webpack_require__.f.j = (chunkId, promises) => {
/******/ 			// import() chunk loading for javascript
/******/ 			var installedChunkData = __webpack_require__.o(installedChunks, chunkId) ? installedChunks[chunkId] : undefined;
/******/ 			if(installedChunkData !== 0) { // 0 means "already installed".
/******/ 	
/******/ 				// a Promise means "currently loading".
/******/ 				if(installedChunkData) {
/******/ 					promises.push(installedChunkData[1]);
/******/ 				} else {
/******/ 					if(!/^(532|666)$/.test(chunkId)) {
/******/ 						// setup Promise in chunk cache
/******/ 						var promise = import("./" + __webpack_require__.u(chunkId)).then(installChunk, (e) => {
/******/ 							if(installedChunks[chunkId] !== 0) installedChunks[chunkId] = undefined;
/******/ 							throw e;
/******/ 						});
/******/ 						var promise = Promise.race([promise, new Promise((resolve) => (installedChunkData = installedChunks[chunkId] = [resolve]))])
/******/ 						promises.push(installedChunkData[1] = promise);
/******/ 					} else installedChunks[chunkId] = 0;
/******/ 				}
/******/ 			}
/******/ 	};
/******/ 	
/******/ 	__webpack_require__.C = installChunk;
/******/ 	
/******/ 	// no on chunks loaded
/******/ })();
/******/ 
/************************************************************************/
/******/ 
/******/ 

What is the expected behavior?
There shouldn't be an error on calling __webpack_require__.X(); i.e. X should be an exsiting property on __webpack_require__.

Other relevant information:
webpack version: 5.46.0
Node.js version: 14.17.3
Operating System: Ubuntu

i get this issue when i run my app :

[webpack.cache.PackFileCacheStrategy] Skipped not serializable cache item 'mini-css-extract-plugin C:\Users\foxxp\OneDrive\Bureau\projects\clones-react-ecomm\ecomm-react-main\gatsby-ecomm\ec\node_modules\gatsby\node_modules\css-loader\dist\cjs.js??ruleSet[1].rules[10].oneOf[0].use[1]!C:\Users\foxxp\OneDrive\Bureau\projects\clones-react-ecomm\ecomm-react-main\gatsby-ecomm\ec\node_modules\gatsby\node_modules\postcss-loader\dist\cjs.js??ruleSet[1].rules[10].oneOf[0].use[2]!C:\Users\foxxp\OneDrive\Bureau\projects\clones-react-ecomm\ecomm-react-main\gatsby-ecomm\ec\node_modules\sass-loader\dist\cjs.js??ruleSet[1].rules[10].oneOf[0].use[3]!C:\Users\foxxp\OneDrive\Bureau\projects\clones-react-ecomm\ecomm-react-main\gatsby-ecomm\ec\src\components\Footer\Footer.module.scss|0|Compilation/modules|C:\Users\foxxp\OneDrive\Bureau\projects\clones-react-ecomm\ecomm-react-main\gatsby-ecomm\ec\node_modules\gatsby\node_modules\css-loader\dist\cjs.js??ruleSet[1].rules[10].oneOf[0].use[1]!C:\Users\foxxp\OneDrive\Bureau\projects\clones-react-ecomm\ecomm-react-main\gatsby-ecomm\ec\node_modules\gatsby\node_modules\postcss-loader\dist\cjs.js??ruleSet[1].rules[10].oneOf[0].use[2]!C:\Users\foxxp\OneDrive\Bureau\projects\clones-react-ecomm\ecomm-react-main\gatsby-ecomm\ec\node_modules\sass-loader\dist\cjs.js??ruleSet[1].rules[10].oneOf[0].use[3]!C:\Users\foxxp\OneDrive\Bureau\projects\clones-react-ecomm\ecomm-react-main\gatsby-ecomm\ec\src\components\Footer\Footer.module.scss': No serializer registered for Warning
<w> while serializing webpack/lib/cache/PackFileCacheStrategy.PackContentItems -> webpack/lib/NormalModule -> Array { 2 items } -> webpack/lib/Mod

also when the page is loading it takes too long due to __webpack_hmr

Feature request

What is the expected behavior?
Since WebAssembly/tool-conventions#65, tooling is expected to emit the custom producer section.

Note that we should only add the Webpack entry and preserve the original producer.

What is motivation or use case for adding/changing the behavior?
For future pipeline/tooling analysis.

How should this be implemented in your opinion?
webassemblyjs

Are you willing to work on this yourself?
yes

Bug report

What is the current behavior?
Error when compiling typescript in target es2022

If the current behavior is a bug, please provide the steps to reproduce.
tsconfig.json

{
   ...
   "compilerOptions" {
       ...
       "target": "ES2022",
       ...
   }
    ...
}

module1.ts

export let userId = document.body.getAttribute("data-user-id")!

module2.ts

import { userId } from "./module1"; 

export class Theme {
    private constructor() {}
    private static Change(isCallback: boolean) {
        localStorage.removeItem('lightTheme_'+userId)
    }
    static {
        localStorage.getItem('lightTheme_'+userId) && this.Change(false)
    }
}

Compiling produces the following file:

...
;// CONCATENATED MODULE: ../ts/module1.ts
let module1_userId = document.body.getAttribute("data-user-id");

;// CONCATENATED MODULE: ../ts/module2.ts

class Theme {
    constructor() { }
    static Change(isCallback) {
        localStorage.removeItem('lightTheme_' + userId);
    }
    static {
        localStorage.getItem('lightTheme_' + module1_userId) && this.Change(false);
    }
}
...

the userId that is in the static block is renamed to module1_userId, and the userId that is in the Change function is not renamed

if you remove static, then all the same, userId will not be renamed inside the class.
In the global context it is renamed normally

What is the expected behavior?
userId must not be renamed to module1_userId. At least this behavior is observed with target = es2021

Other relevant information:
webpack version: 5.74.0
webpack cli version: 4.10.0
Node.js version: 14.19.0
Operating System: Mac Os Mojave 10.14.6
Additional tools:

Current State: opt-in via experiments.css: true

Explainer (not everything is implemented yet):

  • experiments.css: true enables the native css support in webpack
  • This will be enabled by default in webpack 6
  • There will be multiple modes depending on how you reference CSS
    • A: import "./style.css": Attaches the stylesheet to the document as side effect of importing. @import and url() are resolved.
    • B: import stylesheet from "./style.css" asset { type: "css" }: Exports the unattached stylesheet as default export. You can adopt it according to the spec. @import is not allowed (yet), but url() will be resolved.
    • C: import { main } from "./style.module.css": Like A, but renames all css classes, keyframes and css variables and exports the new names. Global selectors are only allowed with explicit :global selector prefix. @import and url() are resolved.
    • D: new URL("./style.css", import.meta.url): Gives an URL to a stylesheet including all styles. @import and url() are resolved.
    • E: import { main } from "./style.module.css": Like C, but for the node.js target. It generates a JSON module with the exports from the CSS.
  • A and C will bundle all CSS of a chunk into a single CSS file (per chunk)
  • splitChunks will allow to move CSS around
  • output.cssFilename and output.cssChunkFilename allows to configure the filename template for css files. By default it copies filename resp. chunkFilename with extension changed to .css
  • HMR will update CSS when you edit it.
  • There is external CSS that will lead to @import "..." in the output css files
  • There are external assets that will lead to a external url.
  • class names are based on module ids, so you need to make sure that SSR and Client module ids match
    • E1: Compute module ids in a deterministic way -> DeterministicModuleIdsPlugin
    • E2: Store module ids in a file and load them on the other side -> SyncModuleIdsPlugin
  • In addition to the default bindings, you can use type: "css/..." in rules to apply loader results as css. e. g. for Sass support.
  • This will replace mini-css-extract-plugin and css-loader
  • It will be more performant, by using a css tokenizer instead of postcss
  • There is a css minimizer in production mode.

Implemented:

  • A
  • @import url("...");
  • @import "...";
  • url()
  • chunking
  • on demand loading
  • HMR
  • splitChunks
  • output.cssFilename
  • external type css-import
  • external type asset
  • :export blocks
  • C (partially)
    • classes
    • ids
    • keyframes + animation
    • css variables + var()
  • correct css order in output file
  • warnings for ordering issues
  • E
  • E1
  • E2

Not implemented/tested, but Planned (ordered by priority):

  • :import blocks
  • C (partially)
    • composes: xxx
    • composes: xxx from "..."
    • composes: xxx from global
    • var(xxx from "...")
    • var(xxx from global)
  • image-set() image()
  • contenthashing for CSS files
  • @import url("...") media query;
  • wasm css tokenizer
  • css minimizer
  • D
  • @import url("...") layer(test);
  • @import url("...") supports(...);
  • B

Known bugs:

  • url() in css leaves a asset JS Module in js chunk

I used webpack 5 with react 18 to auto-generate my HTML and JS files in the dist folder (as you know), but I missed up a bit with my webpack configuration eventually, I didn't succeed to have my dist folder, and I search on other platforms but I didn't find any solutions.
My webpack configuration, package.json, and index.js files are as follows, (hope you can help me to fix the issue):

module.exports = {
  mode: "development",
  devServer: {
    static: path.resolve(__dirname, "./dist"),
    host: 'localhost',
    port: 3000,
    open: true,
  },
  entry: "./src/index.js",
  output: {
    path: path.resolve(__dirname, "./dist"),
    filename: "bundle.js",
    clean: true,
  },
  module: {
    rules: [
      {
        test: /\.(js|jsx)$/,
        exclude: /node_modules/,
        loader: "babel-loader",
      },
      {
        test: /\.css$/i,
        use: ["style-loader", "css-loader"],
      },
      {
        test: /\.(gif|png|jpe?g|svg)$/i,
        use: [
          "file-loader",
          {
            loader: "image-webpack-loader",
            options: {
              bypassOnDebug: true, // webpack@1.x
              disable: true, // webpack@2.x and newer
            },
          },
        ],
      },
    ],
  },
  plugins: [
    new HtmlWebpackPlugin({
      filename: 'index.html',
    }),
  ],
  devtool: "inline-source-map",
};
{
  "name": "dashboard",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "start": "webpack serve --mode development --config config/webpack.config.js",
    "test": "jest"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "dependencies": {
    "@testing-library/jest-dom": "^5.16.5",
    "@wojtekmaj/enzyme-adapter-react-17": "^0.6.7",
    "@zarconontol/enzyme-adapter-react-18": "^0.7.3",
    "clean-webpack-plugin": "^4.0.0",
    "css-loader": "^6.7.1",
    "file-loader": "^6.2.0",
    "image-webpack-loader": "^8.1.0",
    "react": "^18.2.0",
    "react-dom": "^18.2.0",
    "style-loader": "^3.3.1"
  },
  "devDependencies": {
    "@babel/core": "^7.19.3",
    "@babel/preset-env": "^7.19.3",
    "@babel/preset-react": "^7.18.6",
    "@testing-library/react": "^13.4.0",
    "babel-loader": "^8.2.5",
    "chai": "^4.3.6",
    "enzyme": "^3.11.0",
    "enzyme-adapter-react-16": "^1.15.6",
    "enzyme-to-json": "^3.6.2",
    "html-webpack-plugin": "^5.5.0",
    "identity-obj-proxy": "^3.0.0",
    "jest": "^29.1.1",
    "jest-transform-stub": "^2.0.0",
    "webpack": "^5.74.0",
    "webpack-cli": "^4.10.0",
    "webpack-dev-server": "^4.11.1"
  }
}
import React from 'react';
import ReactDOM from 'react-dom/client';
import './index.css';
import App from './App';

ReactDOM.createRoot(document.getElementById('root')).render(
  <React.StrictMode>
    <App />
  </React.StrictMode>
);

Thank you in advance :)