Feature request: local context for entrypoints

🙋 feature request

local or browser-local entrypoint context for environments that load scripts locally.

🤔 Expected Behavior

If entrypoint has a local context, the script elements in the HTML page output should have neither type="module" nor nomodule attributes.

😯 Current Behavior

The HTML page fails to load both the type="module" script and the nomodule script. This is because the browser supports JS modules but there is no server serving the JS files, resulting in a CORS error or invalid MIME error.

💁 Possible Solution

If entrypoint has "context": "local", don’t use type="module" and nomodule, just use the “fallback” script with type="text/javascript" attribute on the HTML element.

🔦 Context

I have an application that runs on specific hardware using a chromium browser locally and functions similarly to electron - uses an HTML entrypoint and necessary assets are fetched locally.

JS modules are supported by the chromium version but I get the error Failed to load module script: The server responded with a non-JavaScript MIME type of "". Strict MIME type checking is enforced for module scripts per HTML spec. because there is no server serving the JS files, they are only being loaded from the filesystem.

I’ve tried using "context": "electron-renderer", but this gives the same HTML output as "context": "browser". The only workarounds I could find were manually changing the HTML output and inlining the entire JS bundle (~1MB) which are not optimal.

The only similar issue I could find was this discussion.

💻 Examples

Build using parcel using an HTML entrypoint that has a JS script element and try to open the resulting HTML in the browser.

[NothingEverWorks]

This is duplicated by https://github.com/parcel-bundler/parcel/issues/7959. Commenting here because this is still open.

I would like support for bundling for the file:/// procotol, but I actually prefer the possible solution from the duplicate feature request; a CLI flag. The advantage of a CLI flag is that it allows a project to be bundled for different usecases (e.g. for file:/// protocol or for a web server) without changing any configuration.

I’ve created a workaround in the following repo. https://github.com/NothingEverWorks/parcel-local-html The workaround fixes the script tags after bundling by using the nomodule index.js output from the differential bundling, that already works with the file:/// procotol and supports synchronous import!

[tedbyron]

Did I understand you correctly that you want to view/run the output from Parcel via a file:// url without a werbserver?

Yes