webpack
Repos
49

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.

61881
8127

Serves a webpack app. Updates the browser on changes. Documentation https://webpack.js.org/configuration/dev-server/.

7465
1341

Repository for webpack documentation and more!

2143
2158

Webpack's Command Line Interface

2404
502

Events

add 2022-04-08 results

Created at 17 minutes ago

add 2022-10-05 results

Created at 39 minutes ago

add 2022-09-30 results

Created at 1 hour ago
started
Created at 1 hour ago
issue comment
Add `i64` to the set of JS-compatible wasm types in `syncWebAssembly` mode

For maintainers only:

  • [ ] This needs to be documented (issue in webpack/webpack.js.org will be filed when merged)
  • [ ] This needs to be backported to webpack 4 (issue will be created when merged)
Created at 1 hour ago
issue comment
Add `i64` to the set of JS-compatible wasm types in `syncWebAssembly` mode

:x: - login: @Liamolucko / name: Liam Murphy . The commit (a74f64e89155e0a8766271aced6abb76c5b9080b) is not authorized under a signed CLA. Please click here to be authorized. For further assistance with EasyCLA, please submit a support request ticket.

Created at 1 hour ago
pull request opened
Add `i64` to the set of JS-compatible wasm types in `syncWebAssembly` mode

For quite a while now, it's been possible for WebAssembly i64s to be converted to/from JS bigints (as function parameters, results, etc.). However, syncWebAssembly mode currently rejects any modules that attempt to do so, because i64 isn't in it's list of JS-compatible types. This fixes that by adding i64 to that list.

Fixes #8531, although that was already closed from inactivity.

(Note: this fix is mainly meant for being backported to webpack 4, since syncWebAssembly is deprecated anyway, but I've implemented it against webpack 5 first.)

This caused rustwasm/wasm-bindgen#3095 when wasm-bindgen switched to directly pass 64-bit integers as i64s rather than as a pair of i32s; that issue is mostly about webpack 4, though, so this'll need to be backported before that's fixed.

There was an existing test that used i64 as an example of a non-JS-compatible type; I replaced that with v128.

Created at 1 hour ago

add 2022-10-05 results

Created at 2 hours ago

add 2022-09-13 results

Created at 2 hours ago
opened issue
A default export must be at the top level of a file or module declaration.

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.

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:

Created at 2 hours ago

add 2021-11-15 results

Created at 3 hours ago

add 2022-08-25 results

Created at 4 hours ago

add 2022-05-18 results

Created at 4 hours ago

add 2022-01-07 results

Created at 5 hours ago
issue comment
Can't resolve *, but it is there.

This sometimes happens when two versions of a module are installed, either globally or locally. Are you sure it's loading the correct module (i.e. from the correct location)?

Why is it loading a module from a Temp folder?

Here are some related issues that might be of some help:

  • https://github.com/babel/babel/issues/14576
  • https://stackoverflow.com/questions/58919016/babel-and-webpack-are-throwing-cant-resolve-regenerator-runtime-runtime
  • https://github.com/bvaughn/react-window/issues/622
  • https://bobbyhadz.com/blog/react-module-not-found-cant-resolve-babel-runtime
Created at 5 hours ago
started
Created at 5 hours ago

add 2021-12-03 results

Created at 6 hours ago
started
Created at 6 hours ago

add 2022-10-05 results

Created at 7 hours ago
started
Created at 7 hours ago
closed issue
Webpack 5 entry dependOn property with UMD exports does not allow AMD loader to load dependent modules

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)
Created at 7 hours ago
started
Created at 8 hours ago

add 2022-07-29 results

Created at 8 hours ago
Created at 8 hours ago
delete branch
dependabot[bot] delete branch dependabot/npm_and_yarn/eslint-plugin-jest-27.1.0
Created at 9 hours ago
pull request closed
Bump eslint-plugin-jest from 24.7.0 to 27.1.0

Bumps eslint-plugin-jest from 24.7.0 to 27.1.0.

Dependabot compatibility score

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


You can trigger Dependabot actions by commenting on this PR:

  • @dependabot rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot merge will merge this PR after your CI passes on it
  • @dependabot squash and merge will squash and merge this PR after your CI passes on it
  • @dependabot cancel merge will cancel a previously requested merge and block automerging
  • @dependabot reopen will reopen this PR if it is closed
  • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
  • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
Created at 9 hours ago
issue comment
Bump eslint-plugin-jest from 24.7.0 to 27.1.0

Superseded by #16337.

Created at 9 hours ago