: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~

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.

1. 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.
2. 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.
3. 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.
4. 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

5. 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.
6. 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.

🎄 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

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

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.

I'm trying to split my vendor code from my app code and got it all working. However, every time I change some code in my app and create a new build, the vendor file gets a new chunkhash and thus is downloaded by the clients again. The contents are exactly the same though.

Here is a fully working small example showing the problem: https://github.com/kevinrenskers/chunkhash-problem

And as you can see, the contents of these files are 100% identical even though the chunkhash keeps changing:

Bug report

What is the current behavior?

I've updated to v4.29.0, and my code is no longer compiling.

Error:

Module parse failed: Unexpected token (11:10)
You may need an appropriate loader to handle this file type.
|       var AsyncHome = asyncComponent(appendAsyncReducer, epicSubject$, function () {
|         return process.env.SERVER ? require('./home')
>         : import(
|         /* webpackChunkName: "books" */
|         './home');
 @ ./server/ssr.js 15:0-34 167:25-34
 @ ./server/index.js

If I revert to v4.28.2, it works again.

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

1. Clone https://github.com/Dbuggerx/react-book-search-sample.git
2. npm i and compile the code (npm run start-server or npm run start) - it should work
3. Now, install webpack v4.29.0 and try to compile again

What is the expected behavior? It should compile the code without errors, as it was doing on v4.28.2

Other relevant information: webpack version: v4.29.0 Node.js version: v10.15.0 Operating System: Fedora linux 29

Hi!

I have two files

require('bootstrap.css')
require('./myfile.css')

where the file bootstrap.css needs to be loaded before ./myfile.css. Is there any way to do set the CSS resolving order properly in webpack for CSS?

updated with the latest versions (29.06.2017) Webpack - 3.0.0 Babel-preset-env - 1.5.2 Node - 8.1.2 OS X - 10.12.5

Current

Tree shaking is not removing imports, not used in the app.

Expected

Tree shaking, removing not used imports.

The test case is a simple app with React & React Router v4. Link component is not used, but the whole router package is bundled.

import React from 'react'
import ReactDOM from 'react-dom'
import { Link } from 'react-router-dom'

ReactDOM.render(
  <p>Hey</p>,
  document.getElementById('app')
)

Webpack & Rollup test repo

Do you want to request a feature or report a bug? bug

What is the current behavior? The memory increased when running webpack4 in development, and the memory didn't release. So there was memory leak. Then node will throw error JavaScript heap out of memory I saw the heapsnapshot, there was many repeated String Objects which were compiled by webpack. If the current behavior is a bug, please provide the steps to reproduce. run webpack development mode with , update the business code and waiting rebuild, then update the code...you will see the increasing memory.

What is the expected behavior? Clear memory in time. If this is a feature request, what is motivation or use case for changing the behavior?

Please mention other relevant information such as the browser version, Node.js version, webpack version, and Operating System. [email protected]

I've met an issue that my npm package (foo for example) need to be used in both webpack4.x and webpack5.x

how to let webpack4.x recognize exports fileds?

Also I can't import through specific path(node_modules path) like foo/bar/baz.js in webpack5.x, got an error path ./bar/baz.js not exported from package

Bumps husky from 6.0.0 to 8.0.3.

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.

This file has a problem with ES module: https://github.com/webpack/webpack/blob/main/hot/poll.js

As per https://webpack.js.org/api/hot-module-replacement/ it should have conditional switch to import.meta.webpackHot

Bumps json5 from 2.2.0 to 2.2.3.

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.

Bug report

I have a private NPM library using typescript exposed through index.js and hosted on private github packages. Importing it in my React.JS Next.JS application bumps into the following runtime error:

error - unhandledRejection: TypeError: _mui_styles_makeStyles__WEBPACK_IMPORTED_MODULE_12__ is not a function
    at eval (webpack-internal:///../../node_modules/@myorg/mylib/build/index.js:106:21)
    at ../../node_modules/@myorg/gvs-kit/build/index.js (/apps/api/.next/server/pages/_app.js:11913:1)
    at __webpack_require__ (/apps/api/.next/server/webpack-runtime.js:33:42)
    at eval (webpack-internal:///./src/modules/MyModule/myFunction.ts:14:76)
    at ./src/modules/MyModule/myFunction.ts (/apps/api/.next/server/pages/_app.js:10303:1)
    at __webpack_require__ (/apps/api/.next/server/webpack-runtime.js:33:42)
    at eval (webpack-internal:///./src/auth/AuthProvider.tsx:13:85)
    at ./src/auth/AuthProvider.tsx (/apps/api/.next/server/pages/_app.js:10083:1)
    at __webpack_require__ (/apps/api/.next/server/webpack-runtime.js:33:42)
    at eval (webpack-internal:///./src/app/App.tsx:13:76)
    at ./src/app/App.tsx (/apps/api/.next/server/pages/_app.js:10017:1)
    at __webpack_require__ (/apps/api/.next/server/webpack-runtime.js:33:42)
    at eval (webpack-internal:///./src/app/Providers.tsx:24:63)
    at ./src/app/Providers.tsx (/apps/api/.next/server/pages/_app.js:10028:1)
    at __webpack_require__ (/apps/api/.next/server/webpack-runtime.js:33:42)
    at eval (webpack-internal:///./pages/_app.tsx:16:76)
    at ./pages/_app.tsx (/apps/api/.next/server/pages/_app.js:9984:1)
    at __webpack_require__ (/apps/api/.next/server/webpack-runtime.js:33:42)
    at __webpack_exec__ (/apps/api/.next/server/pages/_app.js:11934:39)
    at /apps/api/.next/server/pages/_app.js:11935:28
    at Object.<anonymous> (/apps/api/.next/server/pages/_app.js:11938:3)
    at Module._compile (node:internal/modules/cjs/loader:1119:14)
    at Module._extensions..js (node:internal/modules/cjs/loader:1173:10)
    at Module.load (node:internal/modules/cjs/loader:997:32)
    at Module._load (node:internal/modules/cjs/loader:838:12)
    at Module.require (node:internal/modules/cjs/loader:1021:19)
    at require (node:internal/modules/cjs/helpers:103:18)
    at Object.requirePage (/node_modules/next/dist/server/require.js:88:12)
    at /node_modules/next/dist/server/load-components.js:34:54
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async Promise.all (index 1)
    at async Object.loadComponents (/node_modules/next/dist/server/load-components.js:32:33)
    at async DevServer.findPageComponents (/node_modules/next/dist/server/next-server.js:561:36) {
  page: '/'
}
null

Examining the exception line in .next/server/pages/_app.js shows the following:

var _mui_styles_makeStyles__WEBPACK_IMPORTED_MODULE_12__ = __webpack_require__(/*! @mui/styles/makeStyles */ \"../../node_modules/@myorg/mylib/node_modules/@mui/styles/node/makeStyles/index.js\");\n/* harmony import */ 

What is the current behavior?

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

What is the expected behavior?

Other relevant information: webpack version: 5 Node.js version: v18.8.0 Operating System: Ubuntu 22.10 Additional tools: next

Bumps eslint-plugin-jest from 24.7.0 to 27.2.0.

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.