Issue 1:
Bug report

What is the current behavior?

Lets consider the following screenshot:

Even after the control reaches the let assignment statement, the previous imports are undefined. Could anyone explain why is that so?

Also the following shows that the bundled internal variables are defined though:

Why does this behavior exist in javascript? Is this expected or something different.

Its in mozilla firefox browser (95.0.1)

Its undefined even for npm libraries as well, which is in node_modules folder. Why does this happen, which seems slightly not so logical. Is there any issue with the bundler?

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

Create a react app. Introduce redux in it.

Import that store and provide it in the index.js while rendering the root component.

What is the expected behavior?

Just pls explain why is this happening in the browser (firefox 95.0.1) ? Because of this none of the variables imported have any valid values. How to use them in the file post that lines' execution?

Pl give your answer in a more descriptive manner instead of just saying that this behavior is expected. What is exactly this behavior. If this exists how can anyone use any of the imports in the file below? Whats the purpose of importing something you need above, if it will never get imported even after that line is executed?

As far as I know as javascript is a synchronous language except the specific functionalities like promises, async/await, I guess everything else must be synchronous by its design, which is why this unpredictability in its behavior is confusing.

Other relevant information:

webpack version: 5.66.0

Node.js version: 16.13.2

Operating System: Linux

Additional tools:

Dummy code repo created : I also created a dummy repo if anyone looks into it at 12sam12/dummy_app

The question is not about sourcemaps. Its about why the values of the imports used in the unminified or jsx version of files are undefined?? Source maps are nothing and just for the simplicity/conveniency of the debugger. Only when sourcemaps are enabled the client would even be able to view files in this manner and granularity. So already the client is able to view in this manner, which shows that the source maps are enabled.

Then why the following person asked for a test repo in the following discussion??

#15180

Issues and discussions opened on this topic without any response:

#15215

#15180

Issue 2:
Feature request

What is the expected behavior?

Code splitting should work in child compilations without the need for additional configuration.

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

Without an intimate understanding of all of webpack's internal plugins and the hooks they use, it's unclear what functionality you get and don't get when when creating a child compiler. I found it surprising that a child compiler cannot, at minimum, build an app that uses code splitting given that code splitting is not a feature that you usually have to enable otherwise.

In my use case, I'd like to have a 2nd compilation that's almost identical to the parent compilation with the exception that a different optimization option is set. Since the input to both compilations are identical I'd like to reuse as much work as possible across compilations so that webpack doesn't perform 2x the work.

This appears to be the minimal amount of code required to create a compilation similar to the parent:

module.exports = class CopyCatCompilerPlugin {
apply(mainCompiler) {
mainCompiler.hooks.make.tapAsync(
'ChildCompilerPlugin',
(compilation, callback) => {
const childCompiler = compilation.createChildCompiler(
'child',
mainCompiler.options.output,
[
new JsonpTemplatePlugin(), // required since `thisCompilation` taps are not copied
]
);

// required since `compile` taps are not copied by default
childCompiler.hooks.compile.taps = mainCompiler.hooks.compile.taps.slice();

// prevent errors like "Conflict: Multiple assets emit to the same filename 0.js"
// since the child compilation will result is identically named split chunks
childCompiler.options.output.chunkFilename = `child-${mainCompiler.options.output.chunkFilename}`;

// filter out unwanted optimization plugins here

// add identical entry with a different bundle name
new SingleEntryPlugin(
mainCompiler.context,
'./src/index.js',
'main-2'
).apply(childCompiler);

childCompiler.runAsChild(callback);
}
);
}
};

In general, it seems like the pattern of running multiple almost-identical compilations is useful in cases where you want to compile to different targets while not duplicating work across compilation. Or when you want webpack to bundle a test runner bundle but not have the test bundle entry affect your code splits.

Is there a better approach to this problem so that it's easy to replicate the parent compilation with slightly different options while maintaining performance?

For context, I'm on webpack 4.27.1 but cannot migrate to webpack 5 since I have many custom plugins and loaders that will require work to make compatible with webpack 5.

How should this be implemented in your opinion?

Have Compiler.createChildCompiler ensure that the JsonpTempaltePlugin is applied.

Are you willing to work on this yourself?

yes