Live data from Hacker News

TypeScript NPM Packages Done Right

blog.liblab.com

11–20 of 81 posts

Re: TypeScript NPM Packages Done Right

#11

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.

Re: TypeScript NPM Packages Done Right

#12

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

Re: TypeScript NPM Packages Done Right

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

Re: TypeScript NPM Packages Done Right

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

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

Re: TypeScript NPM Packages Done Right

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

Exactly.

Re: TypeScript NPM Packages Done Right

#18
post #16
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.

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

If you're using TypeScript, you have a build step anyway, so you can easily use ESM.

Re: TypeScript NPM Packages Done Right

#19
post #18
post #16

Earlier quoted context omitted.

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

If you're using TypeScript, you have a build step anyway, so you can easily use ESM.

Remember we’re using Node. I don’t think TypeScript compiler supports importing ESM into CommonJS files.

Basically we will have to move the library to ESM and then use a bundler like esbuild to compile it to CJS as well for compatibility. It’s a mess

Post reply on HN