Keep webpackIgnore comments in pyodide.js

[ryanking13]

Description

Resolve #4174

After we changed our build system to esbuild (#3679), /* webpackIgnore */ comments were stripped out after the build.

Since we dynamically import pyodide.asm.js from pyodide.[m]js, this comment is required for webpack bundler (unless we find a better way to deal with this... like merging pyodide.js and pyodide.mjs? I don't know.)

This PR fixes it by putting webpackIgnore comments for every import() statement after building pyodide.js.
A user can do this by adding a webpack plugin, as described in pyodide-webpack-plugin, but I think it is better if we can handle it.

Related:

• WebpackIgnore comments disappear when using esbuild instead of rollup #4004
• Cannot find module 'https://cdn.jsdelivr.net/pyodide/dev/full/pyodide.asm.js' #4174
• Allow arbitrary comments within dynamic imports and constructor calls evanw/esbuild#2721: esbuild added support for preserving magic comments, but it is not compatible with some minify flags.

Checklists

• Add a CHANGELOG entry

[hoodmane]

Thanks @ryanking13!

[hoodmane]

@mneil What's your thought on webpackIgnore comments? Do you think we should just drop them and encourage people to use your plugin?

[mneil]

My opinion is that the library should not make any assumptions about how it will be consumed. Users choosing to bundle with webpack need to understand the implications of choosing that tool and how to work with it. Rollup, Turbopack, esbuild, Webpack, and other tools exist to do the same thing. I'm not sure pyodide should attempt to do anything specifically for one or more of these tools.

The plugin now has a custom loader that skips parsing by webpack so that it doesn't import anything. It's close to adding the ignore comments on the imports. It also handles copying the necessary dependencies like pyodide.asm.js and other files. Obviously I'm biased in favor of the plugin :)

[hoodmane]

close to adding the ignore comments on the imports

Meaning it doesn't do this yet? So maybe we should leave them in for now and then drop all of these once you add support for this?

[mneil]

No, I'm sorry for the confusion. What I meant by "close to adding" is that the functionality is similar, but it is accomplished in a different way. It does not need to add those comments because it doesn't go through webpack's javascript parser anymore.

The comments are not necessary for the plugin to work correctly.

[hoodmane]

Ok then I vote to drop these because they are a wart. If we want to improve webpack-specific support, we should focus on improving the discoverability of the plugin.

[ryanking13]

Thanks for the info! I agree that the handling of bundler-specific things should be handled in the plugin. Maybe let's include this to 0.25.0 for now, and find a way to improve the discoverability of the plugin + test the plugin in the Pyodide repository.

[hoodmane]

include this to 0.25.0 for now, and find a way to improve the discoverability of the plugin + test the plugin in the Pyodide repository

Should we open one or more followup issues for these tasks?

[ryanking13]

I opened a followup issue (#4361)