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?
{
"exports": "dist/index.js"
}
{
"exports": {
".": "dist/index.js",
"./*": "dist/*.js"
}
}
Many packages do this.
It doesn't have to be `index.js` in the root of your package. That's the fallback if no `main` or subpath exports exist in `package.json`
For some projects I just configure publishConfig.directory directly at the dist folder.
While this may not look as clean, it is a lot easier for me to manage everything that’s published under a single directory.
Which doesn't support const enum correctly and god knows what else without erroring.
Also TS enums are flawed: https://blog.logrocket.com/why-typescript-enums-suck/
That’s because its main job is not transpiling to JS, but as a compiler it actually checks the correctness of the code, which is probably the main reason typescript exists in the first place.
You can actually run tsc without emitting JS at all in particular configurations.
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?
Some, but not all of these, are transpilable/polyfillable (refer to compat-table).
Edit: Those numbers are weighted by global usage.
[1] https://caniuse.com/?feats=mdn-javascript_builtins_array_at,...
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.
we have a standard now, CommonJS needs to go, why keep pushing non standard stuff in a 2023 article.
> ▲ Module 'some-library' used by 'src/app/some.component.ts' is not ESM
> CommonJS or AMD dependencies can cause optimization bailouts.
> For more information see: https://angular.io/guide/build#configuring-commonjs-dependen...
Everything should be published as standard modules at this point.
TS module resolution looks almost like ESM, but neither the syntax nor the semantics are the same.
And or course you need a compiler to transpile TS, even if you wish to ignore the typings (often wrapped in a bundler like Vite which in turn wraps swc or ESBuild... because tsc is not as practical for large projects)
Really, having dealt with this kind of problem on Friday, it can make you go crazy.
E.g. having to deal with CJS-specific settings for some tool in a project using TS and exporting to ESM JS...
Libraries especially don't and should be published to npm unbundled. Bundling is purely an application concern.
> Bundling is purely an application concern
by this logic all compiled languages' repos should just be source, no precompiled binaries.
Nope.
So we just use CommonJS with project references and call it a day. Everything works and we don’t need to change any of our code. The way ESM was introduced into Node has been the dumbest decision. And they’re doubling down on it. Excited for Bun to be compatible with my project so that I never have to deal with any of this again.
Any modules that didn't work (e.g. mocha) were switched over to more modern equivalents (vitest). This is probably a good thing.
We also export ESM and CommonJS source in our packages by first transpiling to ESM then using vite to convert to CommonJS. It works really well and allows us to use our packages in both environments.
I started using Rust for quick and dirty programs, web services, small frontend apps - and I noticed: - slower to prototype simple things compared to node CJS - equal or faster when compared to TypeScript - faster to get complex things right
[1] https://nodejs.org/api/packages.html#dual-commonjses-module-...
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.
[0] https://stackoverflow.com/questions/76558023/whts-the-ideal-...
[1] https://github.com/arethetypeswrong/arethetypeswrong.github....
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.
On top of that, being implemented in at least two different environments is a prerequisite to get finalized as a standard per the tc39 process.
I agree with you when it comes to things that aren't far along- the decorator goat rodeo is a good example, but on the whole transpiling is essentially a part of the process now.
If you’re not using Yarn, there seems to be a similar thing on npm, `patch-package`. [2] I never had to use that though.
So that you can test without doing increments which are not required