51–60 of 81 posts
`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?
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.
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.
GPT 4 is great at converting TypeScript to JSDoc
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.
Libraries especially don't and should be published to npm unbundled. Bundling is purely an application concern.
I understand the whole CommonJS Vs imports situation. 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.
The problem is that you can import commonjs modules in ESM but not the other way around. For stepci ( https://stepci.com ) we have chosen to not support ESM for this very reason. We want that the library “just works” for all our users
Everything should be published as standard modules at this point.
Also, the default target configuration is "es2016," and modern browsers only support up to "es2015." 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…
No idea. Matt Pocock has a much better cheat sheet for tsconfig configurations and his is set as es2022. https://twitter.com/mattpocockuk/status/1701619240686485799
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,...
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…
You can specify those exports in package.json. { "exports": "dist/index.js" } or { "exports": { ".": "dist/index.js", "./*": "dist/*.js" } } https://nodejs.org/api/packages.html#subpath-exports Many packages do this.
Earlier quoted context omitted.
No idea. Matt Pocock has a much better cheat sheet for tsconfig configurations and his is set as es2022. https://twitter.com/mattpocockuk/status/1701619240686485799
Link to full cheatsheet: https://www.totaltypescript.com/tsconfig-cheat-sheet
The OP recommends to additionally package src/*.ts along with sourceMaps and declarationMaps.
What's actually the best practice here?
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.
Earlier quoted context omitted.
No idea. Matt Pocock has a much better cheat sheet for tsconfig configurations and his is set as es2022. https://twitter.com/mattpocockuk/status/1701619240686485799
Browser support for ES2015 is about 95% [0], while most ES2022 features sit at around 90% [1]. You can find the individual benchmarks on compat-table [2]. Some, but not all of these, are transpilable/polyfillable (refer to compat-table). Edit: Those numbers are weighted by global usage. [0] https://caniuse.com/es6 [1] https://caniuse.com/?feats=mdn-javascript_builtins_array_at,... [2] https://kangax.github.io/compat-…
Most modern browsers are evergreen, so targeting es2022 would be fine for most users. The exception is Safari, which is slower to incorporate new features and doesn't roll out its updates nearly as quickly as Chromium-based or Firefox, but even they have had es2016 support since 2016.