Option to choose list of files to be copied

[ryanking13]

First of all, thanks for maintaining this project Michael, I really appreciate it.

As mentioned in pyodide/pyodide-webpack-example#7, it would be nice to test this plugin in Pyodide repository and make sure the upstream changes don't break this plugin. For that, I think we need some way to override the list of files to be copied, as upstream changes may add/remove files to be copied.

Maybe something like:

module.exports = {
  plugins: [new PyodidePlugin(
    files: ["pyodide.js", "pyodide.asm.js", "pyodide.asm.wasm"],
  )],
};

[ondrej-stanek-ozobot]

+1 here, great idea! We started using this neat plugin recently. Because our pyodide build has some additional files included in the npm package, we need to patch the lib/patterns.ts source file with additional files. This improvement to the plugin would allow to avoid the patching altogether.

[ondrej-stanek-ozobot]

I would like to propose an alternative to specifying the file list in constructor. Please consider the following:

The list of files that constitute each pyodide build is already listed in the pyodide's package.json file. The pyodide-webpack-plugin already locates and parses the pyodide's package.json file in the tryResolvePyodidePackage function. So perhaps the plugin itself could consult the package.json file of the particular pyodide's build that is to be served, and based on the contents of the files section it would build a list of arguments for the CopyPlugin.

@mneil , what is your opinion on this? Are there any risks or alternate usage scenarios for which this automatic file list retrieval would not work?

[mneil]

@ondrej-stanek-ozobot I do like that idea. This was not the case when the plugin was originally developed. But we could keep the internal list for older versions. Going forward we can rely on the files in the package.json. The one issue I see with that is the files list contains extra data like types definitions and html.

Maybe we could do a combination approach? Copy over the list of files in the "files" property of package.json, exclude html and d.ts files, but also allow an override as Gyeongjae mentioned as an override.

@ryanking13 what do you think about these suggestions?

[hoodmane]

Is copying the html / d.ts files harmful or simply unnecessary?

[mneil]

It is unnecessary and these files would go unused.

[hoodmane]

Presumably there are other unnecessary files in the files list, but there isn't a per-file-extension rule? e.g., what about pyodide.js and pyodide.mjs? Isn't pyodide.js getting webpacked into the main bundle?

[mneil]

Yes, pyodide.js (or pyodide.mjs) are getting put into the main bundle. The plugin does not currently copy either of those over.

[hoodmane]

But if we switch to using the files list then they will get copied? Sorry for my dumb questions. I like this files idea and I think the point is that we only need an overestimate of which files are needed.

[mneil]

Yes, then they would both get copied. These files are copied into the package the user intends to distribute or put into production. There would be a size increase to that output with no benefit to the user.

[hoodmane]

size increase to that output

But these extra files don't get sent to the client browser? So it's not desirable but also not a huge problem?

[mneil]

No, they would not get sent to the browser.

[ryanking13]

@ryanking13 what do you think about these suggestions?

Great! I like the combination approach.