<i>Also, the default target configuration is "es2016," and modern browsers only support up to "es2015."</i><p>I had to recheck this was indeed an article from 2023, because this part surprised me greatly. To my understanding, es2016 only added Array.prototype.includes, the exponentiation operator (**), and preventing generator functions from being constructed. Even the slowest adopters already had these in 2017. Is the author assuming IE11 support?
Is there a reason why npm packages should not target the highest possible target that an LTS Node.js supports? On the front-end those that need lower targets will run their own transpiling anyway to whatever target they want. I'm about to release a few simple npm packages and I'm considering ES2017 as the target (since it has the last major feature - async / await). I'm guessing it's just that the end-user of the library would need to be aware of the polyfills that need to be supplied. I have asked a question [0] about it a while back but it did not get any responses.<p>To clarify - the goal is if you have a project that uses ES7, why would you want to use a package written in ES2020 that is transpiled to, i.e. ES2016 using non-native async / await.<p>[0] <a href="https://stackoverflow.com/questions/76558023/whts-the-ideal-es-target-for-an-npm-package" rel="nofollow noreferrer">https://stackoverflow.com/questions/76558023/whts-the-ideal-...</a>
`tsc` is extremely slow to transpile TypeScript sources into JavaScript. It's invaluable for typechecking, but for transpilation there are much better solutions like SWC or tsup [1] (which nicely wraps esbuild and Rollup).<p>[1] <a href="https://tsup.egoist.dev/" rel="nofollow noreferrer">https://tsup.egoist.dev/</a>
I'm wondering if there's a tool that converts TypeScript into JavaScript that has JsDoc type annotations and preserves API docs? Then you wouldn't need to include anything else. Let the application minify if they choose.
While the article is technically correct it avoids the most common issue with 'pure' typescript libraries in that you still need a bundler if you have multiple .ts files.
Once you enter that territory you realize how much more complex everything becomes.
I understand the whole CommonJS Vs imports situation.<p>I have been that vocal minority that keeps complaining about CommonJS support to library authors. But I have given it up for the greater good.<p>we have a standard now, CommonJS needs to go, why keep pushing non standard stuff in a 2023 article.
Perhaps I’m missing something, but when I’ve done this in the past, I get weird package resolution because my index.js isn’t in the root (`npm publish` publishes the root and doesn’t support alternate paths to my knowledge) - in the end people have to `import x from “mylib/dist”`.<p>I got round this with some funky step where I copy the package.json into the dist folder and rewrite some paths. Is there a better way to do this?
Aslo interesting read on how to push a beta version <a href="https://kevinkreuzer.medium.com/publishing-a-beta-or-alpha-version-to-npm-46035b630dd7" rel="nofollow noreferrer">https://kevinkreuzer.medium.com/publishing-a-beta-or-alpha-v...</a><p>So that you can test without doing increments which are not required
> Will it work with ES Modules (ESM) and CommonJS (CJS) style imports?<p>It's so frustrating that in 2023 this is still a concern. It's probably a bad idea when we adopt the latest JS language standards before they are implemented in the runtime env. Transpiling sucks.
Maybe not related, but if a npm package has conditional exports, what's current best way to patch that package.json ? I want to replace its condition exports with mine.
I'm developing a npm package with just plain javascript modules. No more JS fatigue. I won't ever go back to TypeScript and JS compilers, modern JavaScript is capable enough to stop all this madness.