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.

webpack webpack is a module bundler. Its main purpose is to bundle JavaScript files for usage in a browser, yet it is also capable of transforming, bundling, o

Information

Category: JavaScript / Bundlers
Watchers: 1.5k
Star: 62.8k
Fork: 8.7k
Last update: Mar 26, 2023

Resource links

https://github.com/webpack/webpack

Popular

webpack

webpack is a module bundler. Its main purpose is to bundle JavaScript files for usage in a browser, yet it is also capable of transforming, bundling, or packaging just about any resource or asset.

Install
Introduction
Concepts
Contributing
Support
Core Team
Sponsoring
Premium Partners
Other Backers and Sponsors
Gold Sponsors
Silver Sponsors
Bronze Sponsors
Backers
Special Thanks

Install

Install with npm:

npm install --save-dev webpack

Install with yarn:

yarn add webpack --dev

Introduction

webpack is a bundler for modules. The main purpose is to bundle JavaScript files for usage in a browser, yet it is also capable of transforming, bundling, or packaging just about any resource or asset.

TL;DR

Bundles ES Modules, CommonJS, and AMD modules (even combined).
Can create a single bundle or multiple chunks that are asynchronously loaded at runtime (to reduce initial loading time).
Dependencies are resolved during compilation, reducing the runtime size.
Loaders can preprocess files while compiling, e.g. TypeScript to JavaScript, Handlebars strings to compiled functions, images to Base64, etc.
Highly modular plugin system to do whatever else your application requires.

Get Started

Check out webpack's quick Get Started guide and the other guides.

Browser Compatibility

webpack supports all browsers that are ES5-compliant (IE8 and below are not supported). webpack also needs Promise for import() and require.ensure(). If you want to support older browsers, you will need to load a polyfill before using these expressions.

Concepts

Plugins

webpack has a rich plugin interface. Most of the features within webpack itself use this plugin interface. This makes webpack very flexible.

Name	Status	Install Size	Description
mini-css-extract-plugin			Extracts CSS into separate files. It creates a CSS file per JS file which contains CSS.
compression-webpack-plugin			Prepares compressed versions of assets to serve them with Content-Encoding
i18n-webpack-plugin			Adds i18n support to your bundles
html-webpack-plugin			Simplifies creation of HTML files (`index.html`) to serve your bundles
extract-text-webpack-plugin			Extract text from a bundle, or bundles, into a separate file

Loaders

webpack enables the use of loaders to preprocess files. This allows you to bundle any static resource way beyond JavaScript. You can easily write your own loaders using Node.js.

Loaders are activated by using loadername! prefixes in require() statements, or are automatically applied via regex from your webpack configuration.

Files

Name	Status	Install Size	Description
raw-loader			Loads raw content of a file (utf-8)
val-loader			Executes code as module and considers exports as JS code
url-loader			Works like the file loader, but can return a Data Url if the file is smaller than a limit
file-loader			Emits the file into the output folder and returns the (relative) url

JSON

Name	Status	Install Size	Description
			Loads a JSON file (included by default)
			Loads and transpiles a JSON 5 file
			Loads and transpiles a CSON file

Transpiling

Name	Status	Install Size	Description
`<script>`			Executes a JavaScript file once in global context (like in script tag), `require()`s are not parsed
			Loads ES2015+ code and transpiles to ES5 using Babel
			Loads ES2015+ code and transpiles to ES5 using Traceur
			Loads TypeScript like JavaScript
`awesome-typescript-loader`			Awesome TypeScript loader for webpack
			Loads CoffeeScript like JavaScript

Templating

Name	Status	Install Size	Description
			Exports HTML as string, requires references to static resources
			Loads Pug templates and returns a function
			Compiles Markdown to HTML
			Loads and transforms a HTML file using PostHTML
			Compiles Handlebars to HTML

Styling

Name	Status	Install Size	Description
`<style>`			Add exports of a module as style to DOM
			Loads CSS file with resolved imports and returns CSS code
			Loads and compiles a LESS file
			Loads and compiles a Sass/SCSS file
			Loads and compiles a Stylus file
			Loads and transforms a CSS/SSS file using PostCSS

Linting & Testing

Name	Status	Install Size	Description
			Tests with mocha (Browser/NodeJS)
			PreLoader for linting code using ESLint
			PreLoader for linting code using JSHint

Frameworks

Name	Status	Install Size	Description
			Loads and compiles Vue Components
			Process HTML & CSS with preprocessor of choice and `require()` Web Components like first-class modules
			Loads and compiles Angular 2 Components
			Riot official webpack loader

Performance

webpack uses async I/O and has multiple caching levels. This makes webpack fast and incredibly fast on incremental compilations.

Module Formats

webpack supports ES2015+, CommonJS and AMD modules out of the box. It performs clever static analysis on the AST of your code. It even has an evaluation engine to evaluate simple expressions. This allows you to support most existing libraries out of the box.

Code Splitting

webpack allows you to split your codebase into multiple chunks. Chunks are loaded asynchronously at runtime. This reduces the initial loading time.

Optimizations

webpack can do many optimizations to reduce the output size of your JavaScript by deduplicating frequently used modules, minifying, and giving you full control of what is loaded initially and what is loaded at runtime through code splitting. It can also make your code chunks cache friendly by using hashes.

Contributing

We want contributing to webpack to be fun, enjoyable, and educational for anyone, and everyone. We have a vibrant ecosystem that spans beyond this single repo. We welcome you to check out any of the repositories in our organization or webpack-contrib organization which houses all of our loaders and plugins.

Contributions go far beyond pull requests and commits. Although we love giving you the opportunity to put your stamp on webpack, we also are thrilled to receive a variety of other contributions including:

Documentation updates, enhancements, designs, or bugfixes
Spelling or grammar fixes
README.md corrections or redesigns
Adding unit, or functional tests
Triaging GitHub issues -- especially determining whether an issue still persists or is reproducible.
Searching #webpack on twitter and helping someone else who needs help
Teaching others how to contribute to one of the many webpack's repos!
Blogging, speaking about, or creating tutorials about one of webpack's many features.
Helping others in our webpack gitter channel.

To get started have a look at our documentation on contributing.

If you are worried or don't know where to start, you can always reach out to Sean Larkin (@TheLarkInn) on Twitter or simply submit an issue and a maintainer can help give you guidance!

We have also started a series on our Medium Publication called The Contributor's Guide to webpack. We welcome you to read it and post any questions or responses if you still need help.

Looking to speak about webpack? We'd love to review your talk abstract/CFP! You can email it to webpack [at] opencollective [dot] com and we can give pointers or tips!!!

Creating your own plugins and loaders

If you create a loader or plugin, we would <3 for you to open source it, and put it on npm. We follow the x-loader, x-webpack-plugin naming convention.

Support

We consider webpack to be a low-level tool used not only individually but also layered beneath other awesome tools. Because of its flexibility, webpack isn't always the easiest entry-level solution, however we do believe it is the most powerful. That said, we're always looking for ways to improve and simplify the tool without compromising functionality. If you have any ideas on ways to accomplish this, we're all ears!

If you're just getting started, take a look at our new docs and concepts page. This has a high level overview that is great for beginners!!

Looking for webpack 1 docs? Please check out the old wiki, but note that this deprecated version is no longer supported.

If you want to discuss something or just need help, here is our Gitter room where there are always individuals looking to help out!

If you are still having difficulty, we would love for you to post a question to StackOverflow with the webpack tag. It is much easier to answer questions that include your webpack.config.js and relevant files! So if you can provide them, we'd be extremely grateful (and more likely to help you find the answer!)

If you are twitter savvy you can tweet #webpack with your question and someone should be able to reach out and help also.

If you have discovered a 🐜 or have a feature suggestion, feel free to create an issue on Github.

License

Core Team

Tobias Koppers

Core

Founder of webpack

Johannes Ewald

Loaders & Plugins

Early adopter of webpack

Sean T. Larkin

Public Relations

Founder of the core team

Kees Kluskens

Development

Sponsor

Sponsoring

Most of the core team members, webpack contributors and contributors in the ecosystem do this open source work in their free time. If you use webpack for a serious task, and you'd like us to invest more time on it, please donate. This project increases your income/productivity too. It makes development and applications faster and it reduces the required bandwidth.

This is how we use the donations:

Allow the core team to work on webpack
Thank contributors if they invested a large amount of time in contributing
Support projects in the ecosystem that are of great value for users
Support projects that are voted most (work in progress)
Infrastructure cost
Fees for money handling

Premium Partners

Other Backers and Sponsors

Before we started using OpenCollective, donations were made anonymously. Now that we have made the switch, we would like to acknowledge these sponsors (and the ones who continue to donate using OpenCollective). If we've missed someone, please send us a PR, and we'll add you to this list.

Gold Sponsors

Become a gold sponsor and get your logo on our README on Github with a link to your site.

Silver Sponsors

Become a silver sponsor and get your logo on our README on Github with a link to your site.

Bronze Sponsors

Become a bronze sponsor and get your logo on our README on Github with a link to your site.

Backers

Become a backer and get your image on our README on Github with a link to your site.

Special Thanks to

(In chronological order)

@google for Google Web Toolkit (GWT), which aims to compile Java to JavaScript. It features a similar Code Splitting as webpack.
@medikoo for modules-webmake, which is a similar project. webpack was born because I wanted Code Splitting for modules-webmake. Interestingly the Code Splitting issue is still open (thanks also to @Phoscur for the discussion).
@substack for browserify, which is a similar project and source for many ideas.
@jrburke for require.js, which is a similar project and source for many ideas.
@defunctzombie for the browser-field spec, which makes modules available for node.js, browserify and webpack.
Every early webpack user, which contributed to webpack by writing issues or PRs. You influenced the direction...
@shama, @jhnns and @sokra for maintaining this project
Everyone who has written a loader for webpack. You are the ecosystem...
Everyone I forgot to mention here, but also influenced webpack.

359 Open More issues

Closed

webpack 5 beta feedback

:tada: Thanks for being brave and donating your valuable time to testing unfinished beta software :tada:

webpack 5 is in beta phase now. This means major changes and features are done. Major breaking changes have been added. Basic backward-compatibility has been added.

We want to use the beta phase to do the following:

Let a boarder range of users test the beta version.
Find bugs in new features.
Find regressions in old features.
Find places where a compat-layer can be added to avoid breaking changes.
Improve the migration guide and changelog.

We want to reach these goals after the beta phase:

Old features are very stable
New features are a bit stable
Backward-compatibility layer allows most existing plugins/loader to work unmodified (potentially with deprecation warnings)
There clear way how to migrate from webpack 4 to 5
There are experimental webpack 5 branches for higher-level tools (like angular-cli, vue-cli, create-react-app, ...) (at least 2)

To help with testing you can do the following:

Always test with the latest webpack beta version, as problems might already be fixed there
When using webpack directly:
- Follow the migration guide
- Report or add missing steps in the migration guide
- Report problems during the migration
- Report problems with the build after the migration
When using a higher-level tool:
- Check if there is a branch/Pull Request for webpack 5
- Follow guide there
- Report problems in the Pull Request
Make sure to also report (positive) experience
- Performance comparison
- Size comparison
- DX comparison
Try new features
- Enable persistent caching -> guide
- Enable Top Level Await
- Enable the new asset module type
- Enable Long Term Caching
- Try to break filesystem watching
Trace back deprecation warnings with node --trace-deprecation
- Help upgrading plugins/loaders
Make sure to follow beta releases
- Retest newer version to avoid regressions in beta versions
Consider sponsoring webpack when this version
- increases your productivity with better build performance
- increases your productivity with better developer experience
- increases your consumer happiness with better application performance
- make you happy in some other way...

Known problems:

eval() causes problems with the optimization.innerGraph (production).
libraryTarget: "module" is not implemented yet
devtools don't support persistent caching yet
Persistent Cache file include absolute paths are are not portable yet
import.meta is still missing
prefetching doesn't work for WASM yet
CLI arguments doesn't contribute to cache version
~stack trace is incorrectly displayed in stats~
Build Time is a bit higher for non-cached builds. Possible reasons:
- tracking extra information in the resolver for safe caching
mini-css-extract-plugin is not able to persistent cache yet
https://github.com/webpack-contrib/stylelint-webpack-plugin/issues/187
svg-sprite-loader doesn't work
There is no warning for Buffer or process yet.

Planned breaking changes:

~devtool options will be more restrictive~
Internal HMR API for plugins will probably change
~Disable some webpack-only syntax by default: require.ensure, require.include~
terser-webpack-plugin will be upgraded
~cache.store != "pack" will be removed~

webpack-5

opened Oct 11, 2019 by sokra 507

Closed

Merge Proposal: Module federation and code sharing between bundles. Many builds act as one

This is a proposal to merge my existing work into the Webpack core. The base concept is federated application orchestration at runtime. What I hope will provide a new era for how we build apps at scale.

Due to the demand for more information, we have created a site that consolidates all content

https://module-federation.github.io/

https://github.com/module-federation/module-federation-examples

https://github.com/webpack/changelog-v5/blob/master/guides/module-federation.md

Feature request

@sokra as requested, I've opened a new issue for us to discuss planning and implementation.

This is the evolution of my original issue: https://github.com/webpack/webpack/issues/8524 edit: a better way to explain the request. I want the webpack equivalent of Apollos federation concept. I want to share resources between separate bundles at runtime. Similar to DLL plugin but without needing to provide Static build context , and I want to do this at runtime in the browser. Not at build time. Thus enabling tech like micro-frontends to be efficient, easy to manage, and most importantly - erase page reloads between separate apps and Enable independent deploys of standalone applications.

For context, I've already implemented this feature request with great success. I feel this would have a major impact on frontend applications. I am proposing to refactor/rewrite my project and introduce it into the Webpack core. https://github.com/ScriptedAlchemy/webpack-external-import

What is the expected behavior? import('website-one/MegaNav') require('website-one/MegaNav')

I expect to be able to require modules or chunks from other Webpack bundles hosted elsewhere.
I don't want to manage externals and worry about synchronizing them across systems
I don't want a single point of failure, like a commons chunk
I want to load code from another build, like dynamic imports and code-splitting
I want multiple builds to look and feel like a monolith in the client
I am able to deploy frontend apps independently and expect Webpack to orchestrate at runtime
I don't want to use less integrated/framework oriented solutions like SingleSPA, browser events, service workers - I want to use Webpack as the host container for foreign chunks and modules, not load other app entry points, but rather load other apps chunks and use those modules
If desired, an entire company should be able to federate code across every UI, from user-facing to backend. Effectively turning a multi build, multi team, multi mono-repo company into one SPA in the browser. Removing the need for page reloads or downloading additional code and bundles containing mostly the same node modules

What is motivation or use case for adding/changing the behavior? This would offer a major shift in frontend architecture. Apps are getting larger and code-splitting on its own is not as effective with things such as micro-frontend technology.

All current solutions on the market are substandard - working around the problem instead of addressing it. Application interleaving at runtime enables many new avenues for engineering.

Heres some:

Applications can be self-healing, in the event there is a network failure - one could query other interleaved apps and load their copy of the missing dependency. This would solve deploy issues where pages break for a moment as the new code replaced old
Code can be distributed and managed by the team maintaining it, with options for evergreen code. Navigation, Pages, Routers - could be managed and deployed by the team who owns it - others would not have to redeploy their applications to get updates
Smaller bundles - interleaved apps wouldn't download chunks if Webpack already has the modules required by the interleaved app or fragment.
Easy and feasible micro-frontends - the tech right now involves some serious management and time to build supporting infrastructure
Shareable configs - interleave FE configurations without the need to rebundle or expose multiple configs.
Avoid long & slow builds due to the size of the monorepo. This would enable smaller builds and faster deploys with less coordination across teams
Introduction of "micro-service functions" modeling something similar to what backend engineers get to enjoy.
Better AB testing and marketing tooling. Right now AB tests are managed via a tag manager, plastering vanilla JS onto the dom which is usually not optimized, pollifilled, or compatible with how much javascript apps are written today. Markering teams and AB teams would write native components without having to get in the way of team delivery.
Better analytics - Tag managers and analytics engineers could write system native modules that could be woven into codebases. Most depend on some plugin or just reading the DOM. Interleaving would open a new world of slick integration.
third party modules - vendors could take advantage of this tech and offer managed modules instead of inefficient scripts - they'd still be secure but would have a new way of implementation. Iframes could be avoided in some cases
no global pollution of the window, globals can be accessed via the Webpack runtime
as more apps are interleaved, they too can supply their modules to another interleaved app, resulting in less and less code needing to be downloaded as more and more modules are added to webpack

The use cases are limitless, I've only begun to imagine possibilities.

Webpack is more than capable of doing this without needing any big changes to the core. Both 4 and 5 already have what I need.

How should this be implemented in your opinion? Seeing as I've already done it. I have a clear picture of how to implement it. However, it can be improved with some guidance. I hold little opinion over the solution, as long as it offers a similar outcome.

Add an additional require extension which can support interleaving. I'm currently using a slightly modified version of requireEnsure which already works very well with Webpacks chunk and module loading / caching. when requiring an interleaved module - users would specify a pattern like /<module.id> - Because my current solution is based on requireEnsure, it's pretty robust and not hacky. To handle CSS I've also taken the code template from mini-css to support side-effect loading.
Output an unhashed JS file that can be embedded onto other apps. This file would contain a small mapping of chunk.id to the cache busted file name.
Hashed module ids based on contents + package.json version of dependency + usedExports to support tree-shaken code. Hashing needs to be effective at avoiding collisions as well as to support tree-shaken code. Hashing enables effective code sharing and prevents overwriting existing modules. Ideally, if there's an option to update module id after optimization - it would likely improve the reliability of hashing. However, I have not encountered any problems. Open to alternative solutions. This hashing mechanism I am using is used by amazon who built a CLI to orchestrate code sharing across the company.
A slight addition to the chunk template to include some registration data or another function similar to webpackJsonp.push which registers chunks and provides some metadata to Webpack Heres what it would include:

compilation hash: to detect if this chunk is being loaded by the build that created it, if so, no additional processing is needed
an array of additional chunk.id's required by the current chunk
a list of module ids which allow Webpack to determine if it has all modules required by the chunk about to be interleaved. Webpack would use a lazy find to search modules for the first instance of a missing module.id. At which point Webpack would load the extra chunk needed to fulfill any missing modules it does not already have

an interface similar to externals, where a developer can specify what files/modules they intend to make available for interleaving. During the build, Webpack would not hash these module.ids, but instead, make the id be whatever the key is. Allowing humans to call the module by a predictable name. All dependencies of a module and all modules, in general, would be hashed - ensuring that nested dependencies can be tree shaken and will only use existing modules in Webpack if they are an exact match.
Some automatic chunk splitting which would ensure interleaved files are placed into their own cache group. I also recommend chunking vendor bundles and any loader JS code out of the main chunk in order to avoid interleaving the entry point because of something like css-loader getting grouped into the main chunk. In order to prevent downloading a massive 200kb chunk, I am suggesting that there be some default limit for maxSize set on cache groups. Something along the lines of enabling aggressive code-splitting by default if interleaving is enabled. The goal is a happy medium between not downloading dozens of chunks and not downloading a massive chunk for one or two modules the host build cannot supply.

  "interleave": {
    "TitleComponent": "src/components/Title/index.js",
    "SomeExternalModule": "src/components/hello-world/index.js"
  }

  plugins: [
    new WebpackExternalImport({
      manifestName: "website-one"
    })
  ];

Which would be used in consumer apps like this: require.interleaved('website-one/TitleComponeent')

For better understanding, I suggest reading the links below. Please note that I am aware of many of the less elegant parts of the codebase and eager to improve the implementation to meet internal standards of Webpack (perf, bundle size, implementation strategy, better hooks to use)

https://github.com/ScriptedAlchemy/webpack-external-import
https://github.com/ScriptedAlchemy/webpack-external-import/blob/master/src/webpack/interleaveFn.js
https://github.com/ScriptedAlchemy/webpack-external-import/blob/master/src/webpack/chunkSplitting.js
https://github.com/ScriptedAlchemy/webpack-external-import/blob/master/src/webpack/optimizeChunk.js

Are you willing to work on this yourself? yes - I have been contributing to Webpack since v1 and have a deep understanding of its API. I'd like to be the one to bring this feature to the wider JS community as well as to Webpack. I've built multiple large scale MFEs, some consisting of over 100 MFE's at one company. I am very familiar with the challenges and alternative methods to chunk federation/interleaving - all of them are terrible.

While this solution might not be for everyone, it will have major value to massive corporations consisting of hundreds of teams of FE stacks. I am also able to test implementation updates against my own userbase - providing additional assurance to Webpack. I used the same approach when merging extract-css-chunks with mini-css (bringing HMR to mini-css)

Current results I've been using this system for AB tests, Next.js apps, and config sharing at scale. In a simple comparison. Interleaving three separate React apps produced only 320kb of code transferred (1.2mb uncompressed) compared to 4mb using traditional solutions available on the market.

Extra considerations

Whitelisting instructions that would enable developers to tell Webpack to use the "host build's" version of a dependency. Cases like React where I can't have two on the page - I want to offer the option to have a chunk use the version already installed, even if its a patch version different.
Hashing bloats builds: I'm looking for an alternative solution to hashing to give the community options, however, the savings of code sharing drastically outweigh any overhead in my opinion. 4mb to 1.2mb speaks for itself.
Chunk manifests are inside the chunk - this could be in one single file to produce a single manifest, however, I like the idea of code splitting chunk needs into the chunk themselves. This would make the actual manifest file very small as all it looks up is chunk names to URL paths. Seeing as the manifest is either cache busted with Date.now or 304 cache control - I wanted to keep it lean in the event developers don't want to deal with cache headers and just cache bust the 2kb file on each page load. This would introduce one extra loading wave, as once the chunk is downloaded, it would specify what it needs, triggering Webpack to then download any additional files in one call. Download chunk->download any chunks containing modules Webpack host build cannot provide. Nested chunks would not create more loading waves as the chunk metadata contains a thorough map of what it needs in totality

SSR Update: because this is not only a browser implementation - you are more than able to federate modules via common js and shared directory or volumes on s3 or some other store that system. Alternatively, one could npm install a node version of the dependency at CI, treating the federated code (which is bundled so there’s no need for nested npm installs) to install the latest copy at deploy rendering most recent deploy of it - but at runtime the most updated Versions are available.

Ultimately- if you use module federation for the node build and were to have a shared disk that a lambda could read from, you’d be able to require other code deployed, in the exact same manner as you do on the frontend.

Send a PR

opened Feb 6, 2020 by ScriptedAlchemy 398

Closed

webpack 5 alpha feedback

🎄 First, thanks for trying and giving feedback to our alpha version. 🎄

Note that it's still in an early state and stuff may be broken. This is something you want to report here, as we don't want this to happen in the final release.

Note that the major version has breaking changes and some plugins might no longer work as expected. We try to provided compatibility layers when possible, but some of the changes make this difficult (especially regarding injection additional runtime code). If some plugin isn't working this is also something you should report here to we are at least aware of it and may work on fixing it or adding a compatibility layer.

Here is the full Changelog. Make sure to read at least until the configuration changes to be up-to-date.

If you find something missing in the changelog, this is also something to report here. Easy fixes can made directly in the repo. Every webpack contributor has write access, otherwise send a PR.

If everything is working great, that's also nice to hear. If you are trying the Persistent Caching feature, we would love to see numbers.

Please make sure to try with the lastest alpha version before reporting, as it may already be fixed. You can use the npm dist-tag next to reference the latest alpha version.

package.json "webpack": "next". Update with yarn upgrade webpack / npm update webpack.

Not to forget: Thanks for everybody contributed to this version (@byzyk, @cacheflow, @Connormiha, @fscherwi, @guybedford, @michael-ciniawsky, @niieani, @ooflorent, @SevInf, @smelukov, @sodatea, @sokra, @xtuc). 🎉

Feedback summary:

[x] mini-css-extract-plugin is incompatible (RuntimeModules change)
[x] fork-ts-checker-webpack-plugin is incompatible (frozen hooks)
[ ] circular-dependency-plugin is incompatible (dep.module removed)
[x] cache-loader is no longer needed
[x] webpack-cli misses Stats.presetToOptions (should use compilation.createStatsOptions)
[x] html-webpack-plugin misses fileTimestamps (should use fileSystemInfo)
[x] null prototype objects can't be serialized
[x] Deprecation warning for the HMR defaults
[ ] Docs need update
[x] namedChunkGroups have weird keys
[x] MultiStats.toJson fails without options argument (#8561)
[x] Stats assetsByChunkName is different to v4
[x] node.global: false causes many errors
[x] define is missing require requirement for module
[ ] reasons for scope-hoisted modules are inconsistent
[x] resolve.alias false doesn't work
[x] Source map caching is very slow
[x] Runtime modules duplicated in runtime chunk single
[ ] Compilation.rebuildModule broken in alpha

webpack-5

opened Dec 21, 2018 by sokra 282

Closed

Uncaught TypeError: Cannot read property 'call' of undefined

I'm having an issue with webpack where if I stop watching and restart, it will build just fine, but if I edit a file and save it, the incremental build fails with this error:

Uncaught TypeError: Cannot read property 'call' of undefined

Hunting it down there's a module that does not get included in the incremental change build. Best guess is the path followed to re-make the bundle file is not being followed correctly. Upon re-running (stop and start), the missing module is included.

webpack.config.js (module names changed to protect the innocent):

var webpack = require("webpack"),
    path = require('path')
    ;

module.exports = {
  entry: {
    Entry1: "./app/Entry1.js",
    Entry2: "./app/Entry2.js",
    Entry3: "./app/Entry3.js",
    Entry4: "./app/Entry4.js",
    Entry5: "./app/Entry5.js",
    Entry6: "./app/Entry6.js",
    Entry7: "./app/Entry7.js",
    Entry8: "./app/Entry8.js",
  },
  output: {
    path: path.join(__dirname, "public/js"),
    filename: "[name].bundle.js",
    chunkFilename: "[id].chunk.js"
  },
  module: {
    loaders: [
      {test: /\.js$/, loader: 'jsx-loader'}
    ]
  },
    plugins: [
        new webpack.optimize.CommonsChunkPlugin("shared.js")
    ]
};

bug S2: Inconvenient P2: Very Important

opened Apr 8, 2015 by kfancy 264

Closed

nodejs 17: digital envelope routines::unsupported

Bug report

What is the current behavior?

[webpack-cli] Error: error:0308010C:digital envelope routines::unsupported
    at new Hash (node:internal/crypto/hash:67:19)
    at Object.createHash (node:crypto:130:10)
    at BulkUpdateDecorator.hashFactory (/opt/src/node_modules/webpack/lib/util/createHash.js:155:18)
    at BulkUpdateDecorator.digest (/opt/src/node_modules/webpack/lib/util/createHash.js:80:21)
    at /opt/src/node_modules/webpack/lib/DefinePlugin.js:595:38
    at Hook.eval [as call] (eval at create (/opt/src/node_modules/tapable/lib/HookCodeFactory.js:19:10), <anonymous>:100:1)
    at Hook.CALL_DELEGATE [as _call] (/opt/src/node_modules/tapable/lib/Hook.js:14:14)
    at Compiler.newCompilation (/opt/src/node_modules/webpack/lib/Compiler.js:1053:26)
    at /opt/src/node_modules/webpack/lib/Compiler.js:1097:29
    at Hook.eval [as callAsync] (eval at create (/opt/src/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:6:1) {
  opensslErrorStack: [ 'error:03000086:digital envelope routines::initialization error' ],
  library: 'digital envelope routines',
  reason: 'unsupported',
  code: 'ERR_OSSL_EVP_UNSUPPORTED'
}

Other relevant information: webpack version: 5.59.0 Node.js version: 17.0.0 Operating System: linux x64

webpack-4 webpack-5 critical-bug

opened Oct 19, 2021 by akornatskyy 252

Closed

Source Maps don't work on Chrome

Hello everyone, I just started to use webpack and I'm having serious issues in debugging my code. The problem is that the Chrome debugger doesn't work properly. I'm not sure if this is a webpack issue, a Chrome issue or my fault.

This is my webpack file


var webpack = require('webpack');

module.exports = {
  entry: [
    './app',
  ],
  output: {
    path: __dirname + '/assets',
    publicPath: '/assets',
    filename: 'app.js',
  },
  devServer: {
    contentBase: __dirname + '/assets',
    host: '0.0.0.0',
    port: process.env.PORT,
    historyApiFallback: true,
    watchOptions: {
      aggregateTimeout: 300,
      poll: 1000,
    }
  },
  cache: true,
  devtool: 'inline-source-map',
  plugins: [
    new webpack.HotModuleReplacementPlugin(),
    new webpack.DefinePlugin({
      'process.env.NODE_ENV': '"development"',
    }),
  ],
  module: {
    preLoaders: [
    ],
    loaders: [
      {
        test: /\.js$/,
        include: [ __dirname ],
        exclude: /node_modules/,
        loader: 'babel-loader',
      },
    ],
  },
  node: {
    fs: 'empty',
  },
};

By changing the devtool option I get different behaviours:

eval: the debugger works correctly but the code is really hard to debug because I see the transpiled code
source-map: When I set a brekpoint in a certain line, chrome often moves that breakpoint in another line. When I use the step over functionality, chrome shows me the wrong line even though the line where I stopped the execution was correct (usually the debugger moves the execution indicator where the function is declared)
hidden-source-map: same as eval
inline-source-map: same as source-map
eval-source-map: The debugger adds the breakpoints on the correct line, but the execution never stops. This seems to be connected to #740
cheap-source-map: same as eval
cheap-module-source-map: same as source-map

I've tried to search both Chrome and Webpack related issues, changing browser or anything else it comes in my mind without success.

question

opened Mar 6, 2016 by bolismauro 226

Open

Dynamic import of resources/assets with variable path is broken because such imports are always processed as not having a file extension and are being treated as modules

Bug report

What is the current behavior?

It's impossible to perform a dynamic import of a non-JS module (a PNG picture for example) using variable paths.
The next code will not add a file to a bundle, even if ithe file exists:

const name="picture";
import(  `./resources/${name}.png`);

The problem is in the current module resolving algorithm. I quote the documentation:

Once the path is resolved based on the above rule, the resolver checks to see if the path points to a file or a directory. If the path points to a file:

If the path has a file extension, then the file is bundled straightaway. Otherwise, the file extension is resolved using the resolve.extensions option, which tells the resolver which extensions are acceptable for resolution e.g. .js, .jsx.

But if an import has a variable path (no matter which kind - even if it's a full path with an insertion of a variable containing an empty string), webpack decides that there is no extension and performs a module resolution, which means that the file must have a valid module extension. So only files with ".js", ".ts" and are included into a bundle. The module resolution performed before any module rules are checked but after include/exclude import rules.

What is the expected behavior?

The documentation states and the commons sense tells it must be possible to import other module types than plain JS-modules. If an extension is being provided in the import path, then it must be taken in account. And a specified extension it seems to be the most popular and common case when a non-module is dynamically imported. If no extension is provided/detected then the imported files must be checked and if there are any non-empty "module"-extensions then the module resolution must be performed. The good question is: What should be done if both JS-modules and other file types are detected? There are two main possible choices: not import non-modules in a module has been found (but it can be tricky to execute if a whole subtree is imported), or just import everything and let the user decide (but I suppose that there can be some side effects with importing complex modules). Because of that, I see as the most simple solution is when, webpack might require to always specify an extension if anything else apart from a module is being imported with dynamic import AND variable path. If a user wants several file types to be imported, they can use multiple import statements or use other ways to force webpack to include the files/

Other relevant information: webpack version: 5.76.3 Node.js version: 18.15.0 Operating System: Linux Additional tools:

opened Mar 26, 2023 by Sap333 0

Open

Fix faulty css parser processing

Will make sure

.item div:not(.disabled, .mButtonDisabled, .tipOnly) {
    p-events: initial !important;
}

will be transpiled to

.item div:not(.disabled, .mButtonDisabled, .tipOnly) {
    p-events: initial !important;
}

and not to

.item div:not(.disabled, .mButtonDisabled, .tipOnly {
    p-events: initial !important;
}

Before it missed the closing parenthesis, because it accepted a undefined as an acceptable value for newModeData. Seems like not(.item1, .item2) with multiple items inside the parentheses are not regarded in the parsing logic, because the comma breaks the mode logic. The mode is getting removed and then the closing parenthesis expects there to be a value other than undefined. But there is undefined and that should also not go into the parenthesis. Somehow this now breaks other import logic, if there would be some help that'll be great. I also try to understand it more.

https://github.com/webpack/webpack/discussions/16862

What kind of change does this PR introduce? Bugfix

Did you add tests for your changes? Not yet, I have the config, please point me to adding this testing logic. Thank you.

Does this PR introduce a breaking change?

What needs to be documented once your changes are merged?

The right parentheses in a pseudofunction are missing, seems like that the check for !false returns true on an undefined

PR: unreviewed

opened Mar 25, 2023 by janlent1 2

Open

@swc/helpers is incorrectly removed/tree shaked from the production bundle

Bug report

What is the current behavior?

When using swc-loader with @swc/helpers and mixing ESM and CommonJS it seems that the tree shaking process in webpack incorrectly marks @swc/helpers as not used. When changing the repro below to only use ESM I can no longer reproduce it.

My first instinct was that this was an SWC issue and not a webpack issue, but from what I can tell SWC correcty determines the module type and injects import statements into ESM code and require statements into the CJS code.

Injected into ESM:

import _create_class from "@swc/helpers/src/_create_class.mjs";

Into CJS:

var _create_class = require("@swc/helpers").create_class;

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

I've created a small repro here: https://github.com/andersekdahl/webpack-swc-helpers-repro

entry.js:

import common from "./common";
import esm from "./esm";
console.log(common, esm);

common.js:

const x = class {
  method() {}
};

console.log(x);

module.exports = "commonjs";

esm.js:

const x = class {
  method() {}
};

console.log(x);

export default "esm";

webpack.config.js:

module.exports = {
  entry: "./src/entry.js",
  module: {
    rules: [
      {
        test: /\.js$/,
        use: {
          loader: "swc-loader",
          options: {
            jsc: {
              externalHelpers: true,
            },
            isModule: "unknown",
          },
        },
      },
    ],
  },
};

Prettified final bundle:

(() => {
  var e = {
      915: (e, r, o) => {
        var n = o(835).class_call_check,
          t = o(835).create_class,
          a = (function () {
            "use strict";
            function e() {
              n(this, e);
            }
            return t(e, [{ key: "method", value: function () {} }]), e;
          })();
        console.log(a), (e.exports = "commonjs");
      },
      835: () => {},
    },
    r = {};
  function o(n) {
    var t = r[n];
    if (void 0 !== t) return t.exports;
    var a = (r[n] = { exports: {} });
    return e[n](a, a.exports, o), a.exports;
  }
  (o.n = (e) => {
    var r = e && e.__esModule ? () => e.default : () => e;
    return o.d(r, { a: r }), r;
  }),
    (o.d = (e, r) => {
      for (var n in r)
        o.o(r, n) &&
          !o.o(e, n) &&
          Object.defineProperty(e, n, { enumerable: !0, get: r[n] });
    }),
    (o.o = (e, r) => Object.prototype.hasOwnProperty.call(e, r)),
    (() => {
      "use strict";
      var e = o(915),
        r = o.n(e);
      function n(e, r) {
        for (var o = 0; o < r.length; o++) {
          var n = r[o];
          (n.enumerable = n.enumerable || !1),
            (n.configurable = !0),
            "value" in n && (n.writable = !0),
            Object.defineProperty(e, n.key, n);
        }
      }
      var t = (function () {
        function e() {
          !(function (e, r) {
            if (!(e instanceof r))
              throw new TypeError("Cannot call a class as a function");
          })(this, e);
        }
        var r, o;
        return (
          (r = e),
          (o = [{ key: "method", value: function () {} }]) && n(r.prototype, o),
          e
        );
      })();
      console.log(t), console.log(r(), "esm");
    })();
})();

Note in the final bundle that module id 835 has an empty function that doesn't return the exports create_class and class_call_check as expected.

What is the expected behavior?

That the needed exports from @swc/helpers are still in the final production bundle.

Other relevant information: webpack version: 5.76.3 Node.js version: Tested on 18.13.0 and 16.19.1 Operating System: Tested on Windows and Ubuntu Additional tools:

opened Mar 24, 2023 by andersekdahl 2

Open

Chunk modules are not shared with module federation

Bug report

What is the current behavior? I have the following configuration remote which uses a vendor library (@design-system) from version 4.15.0 a host which uses a vendor library from version 4.18.0 and loads the remote using module federation both the remote and the host share the vendor library using module federation, with the following configuration:

share: {
'@design-systems/components/': {
    singleton: true,
    strictVersion: true,
    requiredVersion: ">=4.0.0 || <=5.0.0"
  }
}

The thing is that components from the library are shared correctly, and are loaded once But, I did noticed that chunks from that library contain the same components, and are loaded several times Here is an example

Consider the following components that exist in the design system package

//button component
export class Button

//card component
import * from '../button';
export class card

import * from '../button';
export class tab

now because the button component is shared, it is extracted to a chunk on build. So, the dist folder of the design system looks like this:

@4.15.0
dist/
      --- chunks/
            chunk.sdhfiuhsad - // button component
      button.js //import chunk.sdhfiuhsad 
      card.js //import chunk.sdhfiuhsad 
      tab.js  //import chunk.sdhfiuhsad

@4.18.0
dist/
      --- chunks/
            chunk.asdasdasdasd - // button component
      button.js. //import chunk.asdasdasdasd
      card.js. //import chunk.asdasdasdasd
      tab.js. //import chunk.asdasdasdasd

Note that the chunk name which contains the button component is different in both versions

Consider the following implementation of the remote component

import * from '@design-system/button'
import * from '@design-system/tab'
import * from '@design-system/card'

Now, when I do the following imports on the host app, I had noticed that button code is imported several time

import {Button} from 'remote/button';
import {Card} from 'remote/card';
import {Tab} from 'remote/tab';
import * from remote/cmp;

I guess it has something to do with the fact that it is part of a chunk, and the chunk name is different in both versions of the design system I had assumed that since the button component is part of the @design-system, and the @design-system is configured to be single, the button file would only be loaded once.

Consider the following diagram for clarity:

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

What is the expected behavior? The expected behavior would be that Webpack would (somehow) Identify that the file contains the button component had already been imported, and would not import in again, although exist as a chunk

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

question webpack-5

opened Mar 23, 2023 by IdoMor 1

Open

Added missing semicolon on the final output

On some external libraries, there is and issue with the minifications of the JS code with this missing semicolon.

Related issue

https://github.com/wp-media/wp-rocket/issues/5512

What kind of change does this PR introduce?

Added missing semicolon on the final output.

Did you add tests for your changes?

Does this PR introduce a breaking change?

No it doesn't.

What needs to be documented once your changes are merged?

Nothing.

PR: unreviewed

opened Mar 22, 2023 by iruzevic 3

Open

Fix Uncaught TypeError: Cannot read properties of undefined (reading …

…‘indexOf’)

When creating a link for a css chunk to be loaded, src is missing. The href is set previously, so we can get via the URL the origin, which is what we need to compare here.

What kind of change does this PR introduce?

Bugfix Did you add tests for your changes? No

Does this PR introduce a breaking change?

What needs to be documented once your changes are merged?

PR: unreviewed

opened Mar 22, 2023 by janlent1 1

v5.76.3(Mar 22, 2023)

Bugfixes

Non-javascript files will correctly not be imported when using experiments.outputModule (ES Module Output) by @snitin315 in https://github.com/webpack/webpack/pull/16809
Limit console output progress bar length to 40 when no columns provided by @snitin315 in https://github.com/webpack/webpack/pull/16810
Add missing NodeJS Builtin Modules support for inspector/promises, readline/promises, and stream/consumers by @ShenHongFei in https://github.com/webpack/webpack/pull/16841
webpack bin/cli now properly respects NODE_PATH env variable by @snitin315 in https://github.com/webpack/webpack/pull/16808
Improve typos in resolveResourceErrorHints by @snitin315 in https://github.com/webpack/webpack/pull/16806
Add missing loaders token support to moduleFilenameTemplate function call by @pgoldberg in https://github.com/webpack/webpack/pull/16756
Add gaurd condition for enabledLibraryTypes in internal ContainerPlugin by @PengBoUESTC in https://github.com/webpack/webpack/pull/16635

New Contributors

@ShenHongFei made their first contribution in https://github.com/webpack/webpack/pull/16841
@pgoldberg made their first contribution in https://github.com/webpack/webpack/pull/16756
@PengBoUESTC made their first contribution in https://github.com/webpack/webpack/pull/16635

Full Changelog: https://github.com/webpack/webpack/compare/v5.76.2...v5.76.3

Source code(tar.gz)
Source code(zip)

v5.76.2(Mar 15, 2023)

Bugfixes

Fix bug where a missing semicolon in generated bundle output for publicPathRuntime would cause concatenated runtime errors by @snitin315 in https://github.com/webpack/webpack/pull/16811
Remove redundant semicolons generated in bundle runtime code after onScriptComplete function by @ahaoboy in https://github.com/webpack/webpack/pull/16347
Fix bug where RealContentHashPlugin was not respecting output.hashSalt's ability to cause a force recalculation of [contenthash] for emitted assets by @dmichon-msft #16789

Performance

Improve memory and runtime performance of sourcemaps via hoisting Regular Expression literals to stored variables by @TheLarkInn in https://github.com/webpack/webpack/pull/15722
Correct v8 deoptimization in ModuleGraph due to instance property declarations occurring outside of constructor by @snitin315 in https://github.com/webpack/webpack/pull/16830

Developer Experience

Improved internal typings to match webpack-sources typings for Source instances by @snitin315 in https://github.com/webpack/webpack/pull/16805
Update repo examples to include missing quotation by @snitin315 in https://github.com/webpack/webpack/pull/16812

New Contributors

@ahaoboy made their first contribution in https://github.com/webpack/webpack/pull/16347

Full Changelog: https://github.com/webpack/webpack/compare/v5.76.1...v5.76.2

Source code(tar.gz)
Source code(zip)

v5.76.1(Mar 10, 2023)

Fixed

Added assert/strict built-in to NodeTargetPlugin

Revert

Improve performance of hashRegExp lookup by @ryanwilsonperkin in https://github.com/webpack/webpack/pull/16759

Source code(tar.gz)
Source code(zip)

v5.76.0(Mar 8, 2023)

Bugfixes

Avoid cross-realm object access by @Jack-Works in https://github.com/webpack/webpack/pull/16500
Improve hash performance via conditional initialization by @lvivski in https://github.com/webpack/webpack/pull/16491
Serialize generatedCode info to fix bug in asset module cache restoration by @ryanwilsonperkin in https://github.com/webpack/webpack/pull/16703
Improve performance of hashRegExp lookup by @ryanwilsonperkin in https://github.com/webpack/webpack/pull/16759

Features

add target to LoaderContext type by @askoufis in https://github.com/webpack/webpack/pull/16781

Security

CVE-2022-37603 fixed by @akhilgkrishnan in https://github.com/webpack/webpack/pull/16446

Repo Changes

Fix HTML5 logo in README by @jakebailey in https://github.com/webpack/webpack/pull/16614
Replace TypeScript logo in README by @jakebailey in https://github.com/webpack/webpack/pull/16613
Update actions/cache dependencies by @piwysocki in https://github.com/webpack/webpack/pull/16493

New Contributors

@Jack-Works made their first contribution in https://github.com/webpack/webpack/pull/16500
@lvivski made their first contribution in https://github.com/webpack/webpack/pull/16491
@jakebailey made their first contribution in https://github.com/webpack/webpack/pull/16614
@akhilgkrishnan made their first contribution in https://github.com/webpack/webpack/pull/16446
@ryanwilsonperkin made their first contribution in https://github.com/webpack/webpack/pull/16703
@piwysocki made their first contribution in https://github.com/webpack/webpack/pull/16493
@askoufis made their first contribution in https://github.com/webpack/webpack/pull/16781

Full Changelog: https://github.com/webpack/webpack/compare/v5.75.0...v5.76.0

Source code(tar.gz)
Source code(zip)

v5.75.0(Nov 9, 2022)

Bugfixes

experiments.* normalize to false when opt-out
avoid NaN%
show the correct error when using a conflicting chunk name in code
HMR code tests existance of window before trying to access it
fix eval-nosources-* actually exclude sources
fix race condition where no module is returned from processing module
fix position of standalong semicolon in runtime code

Features

add support for @import to extenal CSS when using experimental CSS in node
add i64 support to the deprecated WASM implementation

Developer Experience

expose EnableWasmLoadingPlugin
add more typings
generate getters instead of readonly properties in typings to allow overriding them

Source code(tar.gz)
Source code(zip)

v5.74.0(Jul 25, 2022)

Features

add resolve.extensionAlias option which allows to alias extensions
- This is useful when you are forced to add the .js extension to imports when the file really has a .ts extension (typescript + "type": "module")
add support for ES2022 features like static blocks
add Tree Shaking support for ProvidePlugin

Bugfixes

fix persistent cache when some build dependencies are on a different windows drive
make order of evaluation of side-effect-free modules deterministic between concatenated and non-concatenated modules
remove left-over from debugging in TLA/async modules runtime code
remove unneeded extra 1s timestamp offset during watching when files are actually untouched
- This sometimes caused an additional second build which are not really needed
fix shareScope option for ModuleFederationPlugin
set "use-credentials" also for same origin scripts

Performance

Improve memory usage and performance of aggregating needed files/directories for watching
- This affects rebuild performance

Extensibility

export HarmonyImportDependency for plugins

Source code(tar.gz)
Source code(zip)

vue-loaders loaders.cssvue-loaders - vue wrappers for loaders.css

Module bundler with support for code splitting, ES6 & CommonJS modules.

A Babel 7 plugin transform to convert CommonJS into ES Modules

One Click, Offline, CommonJS Modules in the browser

MIVisionX toolkit is a set of comprehensive computer vision and machine intelligence libraries, utilities, and applications bundled into a single toolkit. AMD MIVisionX also delivers a highly optimized open-source implementation of the Khronos OpenVX™ and OpenVX™ Extensions.

CSS Spinners and Loaders - Modular, Customizable and Single HTML Element Code for Pure CSS Loader and Spinner

Pure css loading animations. As long as only one element!

Single GPU Passthrough for AMD devices

A Unity package for splitting meshes at runtime.

CSS Loaders is a collection of different types of CSS loaders, spinners and their source code

Read and modify memory timings on the fly

vue-ts-amd - A full-featured Vue.js 2 boilerplate using AMD pattern (RequireJS) and Typescript.

ADE20K is composed of more than 27K images from the SUN and Places databases

A Jinja extension (compatible with Flask and other frameworks) to compile and/or compress your assets.

code splitting as a component

:o: A collection of pure CSS React loading components

CommonJS Tree Shaker plugin for WebPack

A collection of animated loaders made with pure CSS and 🖤

Embedded CoffeeScript templates

General purpose GPU compute framework for cross vendor graphics cards (AMD, Qualcomm, NVIDIA & friends).

Share this repo

Related Repos

Bundlers

This is a Webpack Project about Todo-list which you can add your to-dos, edit them, add ma...

Todo-list-webpack This website Todo-list-webpack provides users a convenient way to keep track of their todos. Built With HTML CSS JavaScript Linters

Bundlers

This is a Webpack Project Leaderboard and uses API to add your game score and see a list o...

Leaderboard This is a Webpack Project Leaderboard and use API to add your game score and see a list of the other scores What I did in this project: Se

Bundlers

A boilerplate code to build a chrome extension with react and webpack.

Chrome Extension with React.js Boilerplate Boilerplate for your chrome extension with react.js and webpack Background Creating a file structure for de

Bundlers

To-do is a web app that helps to organize your day to day activities.

To-do is a web app that helps to organize your day to day activities. It lists all the activities that you need to be completed and allows you to mark them as complete or not. It's a minimalistic website built using JavaScript ES6, Webpack and CSS.

Bundlers

825

enterprise standard loader

ESL (Enterprise Standard Loader) ESL是一个浏览器端、符合AMD的标准加载器，适合用于现代Web浏览器端应用的入口与模块管理。 ESL is a browser-only, amd-compliant module loader. In modern web app

Bundlers

CSS Loader

css-loader The css-loader interprets @import and url() like import/require() and will resolve them. Getting Started ⚠ To use css-loader, [email protected] is

Bundlers

4.9k

The power of webpack, distilled for the rest of us.

Introduction Laravel Mix provides a clean, fluent API for defining basic webpack build steps for your applications. Mix supports several common CSS an

Bundlers

Utility functions to test Webpack loaders/plugins

webpack-test-utils Utility functions to test Webpack loaders/plugins Features In-memory builds Uses an in-memory file-system for faster builds that do

Bundlers

Vue 3 Server Side Rendering with Webpack 4 Hot Module Replacement

Vue 3 SSR with Webpack 4 HMR Play with it right in the browser! Features Hot reloading for everything inside src folder Production-ready build Integra

Bundlers

bundle and `require` a file

💛 You can help the author become a full-time open-source maintainer by sponsoring him on GitHub. bundle-require Use Case Projects like Vite need to l

Bundlers

430

TypeScript Module Loader

TypeScript Module Loader Features Supports node <file> usage Supports ESM --loader usage† Supports --require hook usage Optional configuration file fo

Bundlers

Webpack plugin to tree-shake and minify JSON modules

webpack-json-access-optimizer Optimize JSON modules that are referenced via accessor function. For example, i18n locale JSONs. Features Tree shaking R

Bundlers

Experimental wasm linker

zwld Experimental linker for wasm object files. The idea is to implement a linker that stays close to wasm-ld in regards to features so that one day t

Bundlers

EMP Micro FE Base on webpack 5 & module federation

EMP - Micro Frontends solution Base on Webpack 5 & Module Federation English | 简体中文 Projects Project NPM Info @efox/emp-cli CLI @efox/emp-tsconfig Typ

Bundlers

This is a restaurant page developed with JS and webpack, following The Odin Project JS cur...

Sushi Hub restaurant page This is a Sushi Hub restaurant web page, you'll find ancient Japanese foods in our specials section Note: Only large screens

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.

webpack

Table of Contents

Install

Introduction

Get Started

Browser Compatibility

Concepts

Files

JSON

Transpiling

Templating

Styling

Linting & Testing

Frameworks

Performance

Module Formats

Contributing

Creating your own plugins and loaders

Support

License

Core Team

Sponsoring

Premium Partners

Other Backers and Sponsors

Gold Sponsors

Silver Sponsors

Bronze Sponsors

Backers

Special Thanks to

Feature request

Bug report

Bug report

Bug report

Bug report

v5.76.3(Mar 22, 2023)

Bugfixes

New Contributors

v5.76.2(Mar 15, 2023)

Bugfixes

Performance

Developer Experience

New Contributors

v5.76.1(Mar 10, 2023)

Fixed

Revert

v5.76.0(Mar 8, 2023)

Bugfixes

Features

Security

Repo Changes

New Contributors

v5.75.0(Nov 9, 2022)

Bugfixes

Features

Developer Experience

v5.74.0(Jul 25, 2022)

Features

Bugfixes

Performance

Extensibility

Related Repos