Issue 1:
Bug report

I initially opened this as an issue in karma-webpack, but found the code responsible to be in webpack@5.x.x.

What is the current behavior?

Uncaught TypeError: Cannot read property 'webpackChunk' of undefined
at C:/Users/%USERNAME%/AppData/Local/Temp/_karma_webpack_645953/runtime.js:100:64

TypeError: Cannot read property 'webpackChunk' of undefined
at C:/Users/%USERNAME%/AppData/Local/Temp/_karma_webpack_645953/runtime.js:100:64
at C:/Users/%USERNAME%/AppData/Local/Temp/_karma_webpack_645953/runtime.js:130:12
at C:/Users/%USERNAME%/AppData/Local/Temp/_karma_webpack_645953/runtime.js:137:12

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

set output.globalObject to "this"

setting output.libraryTarget to "umd" does not seem to change the end result

What is the expected behavior?

No errors to be thrown by Webpack's bootstrap code.

Other relevant information:

webpack version: 5.23.0

Node.js version: 14.2.0

Operating System: Windows 10

Additional tools:

NPM Version: 6.14.11 (yarn: 1.22.5)

see package.json below for more tools (10 dependencies total, including webpack)

minimal package.json

// ./package.json
{
"private": true,
"scripts": {
"test": "karma start"
},
"devDependencies": {
"@babel/core": "7.12.17",
"@babel/preset-env": "7.12.17",
"babel-loader": "8.2.2",
"core-js": "3.9.0",
"karma": "6.1.1",
"karma-chrome-launcher": "3.1.0",
"karma-ie-launcher": "1.0.0",
"karma-jasmine": "4.0.1",
"karma-webpack": "5.0.0",
"webpack": "5.23.0"
},
"browserslist": [
"last 1 chrome version",
"last 1 edge version",
"last 1 firefox version",
"last 1 safari version",
"ie 11"
]
}

babel, webpack, and karma configurations

My original webpack configuration was a modified version of react-scripts, which also uses output.globalObject: "this".

While debugging the error, I stripped karma, webpack, and babel configurations to the minimum:

// ./karma.conf.js
process.env.BABEL_ENV = 'test'
process.env.NODE_ENV = 'test'

const path = require('path')

module.exports = function(config) {
config.set({
plugins: [
'karma-chrome-launcher',
'karma-ie-launcher',
'karma-jasmine',
'karma-webpack',
],
browsers: ['IE', 'Chrome'],
frameworks: ['jasmine', 'webpack'],
files: [{pattern: 'src/**/*.test.js', watched: false}],
preprocessors: {'src/**/*.test.js': ['webpack']},
reporters: ['progress'],
webpack: {
mode: 'development',
devtool: 'inline-source-map',
output: {
globalObject: 'this'
},
module: {
rules: [
{
test: /\.(js|mjs|jsx|ts|tsx|cjs)$/,
include: [path.resolve(__dirname, 'src')],
loader: 'babel-loader',
options: {
// babel-loader specific options
cacheDirectory: false,
cacheCompression: false,

// babel options
compact: false,
presets: [
[
'@babel/preset-env',
{
useBuiltIns: 'entry',
corejs: '3.9',
}
]
]
}
}
]
}
}
})
}

entry point code

// ./src/foo.test.js
it('should pass', () => {
expect(true).toBe(true)
})

The cause of the problem seems to be the bootstrap code using strict mode without setting the execution context, so "this" results in undefined instead of a reference to the window object.

Issue 2:
I've recently run into a bit of a frustrating situation trying to provide ESM build of libraries along-side commonjs ones. Ideally the ESM code should always be used by webpack, and allow cherry picking modules (as to not have to rely solely on treeshaking).

Currently, with the strictness of importing none mjs files into .mjs we can't compile the same codebase in a way that works as cjs or esm modules. take the following example:

_MyComponent.mjs

import { polyfill } from 'react-lifecycle-compat';

// use polyfill(Component) etc.

react-lifecycle-compat exposes both a esm build (.js) and a cjs file here (compiled esm -> cjs)

What I want to do is compile MyComponent.mjs with babel to MyComponent.js and ship both files, relying on webpack to resolve the .mjs file before the .js one. However this won't work.

react-lifecycle-compat is not .mjs so webpack considers it not an esm file and requires i write the import as: import ReactLifeCycleCompat from 'react-lifecycle-compat';,

Compiling this to cjs will also break, because of react-lifecycle-compat's __esmodule flag, so I can't import that as a default because babel sees taht it's only named exports.

TL: DR;

Consuming compiled, __esmodule flagged, modules with name exports cannot be written in a way that satisfies both cjs and mjs consumers.

I realize I can configure webpack to treat mjs as javascript/auto but that's not ideal, because I'm interested in providing libraries that can be consumed by webpack and node witthout requiring users to configure something, while also wanting to move towards future standards and take advantage of esm optimizations