Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TypeScript NPM Packages Done Right

blog.liblab.com

Post reply on HN
Print view View original

61–70 of 81 posts

Re: TypeScript NPM Packages Done Right

#61

Post by rattray »

paulddraper wrote: post #11
wuiheerfoj wrote: post #4

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.

Note that jest before v27, and some other runtimes, don't support export maps.

Re: TypeScript NPM Packages Done Right

#62

Post by nwienert »

lolinder wrote: post #60
n2d4 wrote: post #56

Earlier quoted context omitted.

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-…

When we talk about "modern browsers", we're not talking about usage percentage, we're talking about browsers released in the past few years. If you need to support browsers older than that, that's great, but we don't call those modern browsers, that's legacy support. Most modern browsers are evergreen, so targeting es2022 would be fine for most users. The exception is Safari, which is slower to incorporate new featur…

Also Safari greatly picked up pace a few years ago and honestly it’s hard to categorize them as behind anymore. They lead in several areas, and have caught up in most.

Re: TypeScript NPM Packages Done Right

#63

Post by mckravchyk »

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.

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-...

Re: TypeScript NPM Packages Done Right

#64

Post by paulddraper »

rattray wrote: post #61
paulddraper wrote: post #11

Earlier quoted context omitted.

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.

Note that jest before v27, and some other runtimes, don't support export maps.

Jest and every other major runtime/bundler has supported exports for a couple years.

I.e. if you're releasing a package today, you probably don't have to worry about support.

Re: TypeScript NPM Packages Done Right

#65

Post by n2d4 »

lolinder wrote: post #60
n2d4 wrote: post #56

Earlier quoted context omitted.

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-…

When we talk about "modern browsers", we're not talking about usage percentage, we're talking about browsers released in the past few years. If you need to support browsers older than that, that's great, but we don't call those modern browsers, that's legacy support. Most modern browsers are evergreen, so targeting es2022 would be fine for most users. The exception is Safari, which is slower to incorporate new featur…

Sure, but the reason why browser compatibility is being measured is to quantify that notion of "modern".

You can then use that to make your own decisions; if you're working on a high-tech video streaming platform for kids you can probably safely ignore the 5%, but if you're providing information on behalf of the government you might need to support much more than that.

Re: TypeScript NPM Packages Done Right

#66

Post by n2d4 »

mckravchyk wrote: post #63

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 lib…

Some people write ES2015 code without any ES2016+ transpilers or polyfills (for both good and bad reasons). They might also be using different transpilers with varying settings (such as TypeScript's downlevelIteration, whose default value), and your package would then show different behaviour. And many setups don't transpile anything inside node_modules.

Re: TypeScript NPM Packages Done Right

#67

Post by psnehanshu »

meiraleal wrote: post #23

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.

Then atleast use JSDoc. Type definitions greatly help the users of your package.

Re: TypeScript NPM Packages Done Right

#68

Post by c-hendricks »

skybrian wrote: post #48

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.

Does the typescript language server even look at jsdoc comments in libraries?

Re: TypeScript NPM Packages Done Right

#69

Post by rasso »

c-hendricks wrote: post #68
skybrian wrote: post #48

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.

Does the typescript language server even look at jsdoc comments in libraries?

Yes it does

Re: TypeScript NPM Packages Done Right

#70

Post by JuanPosadas »

arbol wrote: post #39
krona wrote: post #24

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 flawed

I like Typescript enums generally, my only complaint is that they are kept in the final build as big objects, especially in the scenario where you don't enumerate them. I use a replace function with terser to replace them with inlined constants to make my fine build smaller.

Post reply on HN