|
|
|
|
|
by smt88
1682 days ago
|
|
Yes, I know JavaScript has native modules at the language level, but they are not universally supported. Most importantly, there can't/won't be a breaking change for the previous iterations of module import, so we will continue to have many different ways to import. It's not an issue of whether JS has a "blessed" way of doing it (and it didn't even have that for a long time). It's that there's more than 3 ways to do it, and many of them look similar and have confusing conflicts with compilers/packagers. |
|
The four environments I often end up with are: Browser, Node.js, Rollup.js, and TypeScript.
For example, for a long time now, it has been sensible to just use "import" statements in code you intend to run in the browser. For a debug build, you don’t have to bundle, since browsers support import, but the imports have to be relative and have the full pathname. Node.js has a configuration option that allows you to use "import", but it is finicky and it can be surprising how many things will break when you turn it on—the alternative is to use ".mjs" as an extension. TypeScript has specific requirements about file extensions as well, and does not modify them. Finally, Rollup.js is hopelessly configurable.
Consider a simple requirement, “This code runs in the browser, I want to write a test using Jest.” I know it can be done, but I’m spending a bunch of time digging through forum posts to make it work, and understand how to make Jest load the code that already runs in the Browser, because the Node.js environment is so different… and most of the time, I end up writing code just to get something to build.
So the more than 3 ways, off the top of my head:
- Import paths: non-relative? relative? relative with leading slash?
- Import paths: .js suffix? no .js suffix?
- Files: use .mjs / .js suffix? use .js / .cjs suffix?