3 ms·

Because using a JS module will set back your 30-minutes project by an entire day. Of course you are supposed to master which of the es/interop/amd/require inca

Because using a JS module will set back your 30-minutes project by an entire day. Of course you are supposed to master which of the es/interop/amd/require incantation you are supposed to use. I wish Typescript would have mandated one style and one style of JS module only!! And I’ve never succeeded to find a good guidelines on which kind of JS module I should use. Any advice on what is a very easy and stable and worth-to-learn technique to master imports in 2024?

genuinelydang 2y ago
What? If you don’t have external dependencies, just remove your bundler/transpiler and rely on browsers to import your code.
afavour 2y ago
Your rant is several years out of date. You can use ES imports natively in Node and the browser. I have been very happy doing so. Besides, if you’re working with a codebase of non-zero complexity you need imports/require/whatever anyway.
jazzypants 2y ago
Use ESM. It's built into the browser. CJS is legacy. Every major JS runtime has module interop built in now. Modules aren't hard anymore.
nsonha 2y ago
> Because using (a JS) module will set back your 30-minutes project by an entire day May be learn to do the basic of YOUR JOB for once, some "software engineer".
WorldMaker 2y ago
In 2024 the one and only answer is finally just ESM. If you need to support the browser use `<script type="module">`. That works natively in every current browser today. You may need an "importmap" for more easily handling dependencies. You may need to spot build with something like esbuild or rollup or rolldown for some of your dependencies if they were written in CJS or to add missing things a browser needs like ".js" file extensions. If you need to support Node use the package.json incantation `"type": "module"` and the `"exports"` key instead of `"main"` and get sane modern defaults in all LTS supported versions of Node (and a few past versions now, too). Most imports will "just work", your module files will be sensibly named ".js". If you publish a library, most people can consume it, even if some of them (CJS stalwarts/people trapped in legacy swamps) complain about having to work with Promises some of the time. If you need to support Deno or Bun, they already have sane defaults and their documentation guides you pretty well, including Typescript setup. > I wish Typescript would have mandated one style and one style of JS module only!! The good news it that they kind of did: the import/export syntax that Typescript has made familiar since around TS 1.0/1.5 is "surprise" ESM syntax. Typescript has been preparing developers into using it all along. You can stop cross-compiling the ESM you've already become used to writing to older, worse formats like CJS and AMD, you can let Typescript do a lot less work on your behalf and just "strip types" more than "transpile".

genuinelydang 2y ago

What? If you don’t have external dependencies, just remove your bundler/transpiler and rely on browsers to import your code.

afavour 2y ago

Your rant is several years out of date. You can use ES imports natively in Node and the browser. I have been very happy doing so. Besides, if you’re working with a codebase of non-zero complexity you need imports/require/whatever anyway.

jazzypants 2y ago

Use ESM. It's built into the browser. CJS is legacy. Every major JS runtime has module interop built in now. Modules aren't hard anymore.

nsonha 2y ago

> Because using (a JS) module will set back your 30-minutes project by an entire day May be learn to do the basic of YOUR JOB for once, some "software engineer".

WorldMaker 2y ago

In 2024 the one and only answer is finally just ESM. If you need to support the browser use `<script type="module">`. That works natively in every current browser today. You may need an "importmap" for more easily handling dependencies. You may need to spot build with something like esbuild or rollup or rolldown for some of your dependencies if they were written in CJS or to add missing things a browser needs like ".js" file extensions. If you need to support Node use the package.json incantation `"type": "module"` and the `"exports"` key instead of `"main"` and get sane modern defaults in all LTS supported versions of Node (and a few past versions now, too). Most imports will "just work", your module files will be sensibly named ".js". If you publish a library, most people can consume it, even if some of them (CJS stalwarts/people trapped in legacy swamps) complain about having to work with Promises some of the time. If you need to support Deno or Bun, they already have sane defaults and their documentation guides you pretty well, including Typescript setup. > I wish Typescript would have mandated one style and one style of JS module only!! The good news it that they kind of did: the import/export syntax that Typescript has made familiar since around TS 1.0/1.5 is "surprise" ESM syntax. Typescript has been preparing developers into using it all along. You can stop cross-compiling the ESM you've already become used to writing to older, worse formats like CJS and AMD, you can let Typescript do a lot less work on your behalf and just "strip types" more than "transpile".