41–50 of 81 posts
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.
Earlier quoted context omitted.
> much better solutions like SWC Which doesn't support const enum correctly and god knows what else without erroring.
Esbuild works fine and is also much faster than TSC. Also TS enums are flawed: https://blog.logrocket.com/why-typescript-enums-suck/
> Enums in TypeScript are a very useful addition to the JavaScript language when used properly.
So, just like any language feature.
> Will it work with ES Modules (ESM) and CommonJS (CJS) style imports? 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.
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.
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.
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”`. 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…
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`
`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). [1] https://tsup.egoist.dev/
`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). [1] https://tsup.egoist.dev/
Why do you need it to be fast?
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.
You don't necessarily need a bundler. You could use index.ts files to re-export all the exports of your source files.
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...