3 ms·
Sadly ESM don't work with local files (file:// protocol).
by codedokode 2y ago
Sadly ESM don't work with local files (file:// protocol).
- graypegg 2y agoThat would be expected for a browser environment though! I don’t want any module my browser imports to silently import something off the filesystem without telling me.
- em-bee 2y agowhile i agree with that, i don't quite understand why this is an issue if the main index.html file is from the local filesystem too. the filesystem should only be off limits if the main file is loaded from a website.
- em-bee 2y agoi suppose the problem is mixing local and remote sources. i don't know if blocking remote sources from loading local ones is enough or even easy to do. if not then that would explain why local needs to be blocked.
- WorldMaker 2y agoMost systems come with Python today, so starting an HTTP server for local testing is often a one-liner like `python -m http.server`. Anyone already working with Node has access to one-liners like `npx http-server`. (Deno and Bun also have one-liners.)
- codedokode 2y agoIt is not that easy. You need to open console and navigate to the project directory first. While with ordinary HTML files all you need is to start typing its name in address bar (or simply never close the tab).
- WorldMaker 2y agoThis isn't ESM's fault, this is the CORS security model that applies to all JS in most browsers. Some of the browser's "grandfather in" some looser restrictions for file:// origin JS files from file:// origin HTML files, with Firefox being the least restrictive I'm aware of, but you can trigger CORS blocks in all of them for JS files of many types, not just ESM. ESM just wound up on the other side of the expiration of "grandfathered in" loose restrictions for CORS checks in most browsers. Sure, there's a learning curve to running even a one-liner localhost HTTP server, but when I was learning HTML the first time there were all sorts of strange learning curves (many of which aren't even relevant anymore). Sure, it makes it harder to distribute things like Twine apps, but there are known workarounds (bundle all the scripts into the HTML file) that Twine already does. (I'd love to see a new well-supported "HTML app container" format/standard to download/distribute HTML apps safely. It seems unfortunate that PWAs went so deep into Service Worker mania and the simple ideas like I should be able to ZIP a folder of HTML and JS files, rename it to something like myapp.pwa and it "just work" kind of got lost in several shuffles. Sure, Service Worker-based file auto-updating is nice when it works, but it is so complicated and sometimes I just want a dumb ZIP-like file users can double-click.)