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

1–10 of 81 posts

Re: TypeScript NPM Packages Done Right

#2

Post by GrygrFlzr »

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 assuming IE11 support?

Re: TypeScript NPM Packages Done Right

#3

Post by evnix »

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.

Re: TypeScript NPM Packages Done Right

#4

Post by wuiheerfoj »

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 do this?

Re: TypeScript NPM Packages Done Right

#5

Post by nrabulinski »

GrygrFlzr wrote: post #2

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…

Yes, even ES2019 features have been supported by most mainstream browsers since late 2018, and by all of them by 2020

Re: TypeScript NPM Packages Done Right

#7

Post by iainmerrick »

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…

It should work as you expect if you set “main” to “dist/index.js” in your package.json. If you tried that, some other strange thing must have been going wrong. Your workaround sounds fine but ideally you shouldn’t need it, yeah.

Re: TypeScript NPM Packages Done Right

#8

Post by [deleted] »

evnix wrote: post #3

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.

[deleted]

Re: TypeScript NPM Packages Done Right

#9

Post by aiunboxed »

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…

Yup, we have a script which does exactly the same, copies to the main folder and then pushes.
Post reply on HN