search

arethetypeswrong / arethetypeswrong.github.io

Tool for analyzing TypeScript types of npm packages
https://arethetypeswrong.github.io
MIT License
1.12k stars 38 forks source link

Proposal: support publishConfig #172

Closed waldronmatt closed 2 months ago

waldronmatt commented 3 months ago

First I want to say thank you for this tool, it has been extremely helpful to ensure type compliance on packages.

I've recently adopted a technique in my monorepo where I use my package exports to point to source ts files so VS Code will reflect "live" types even across package boundaries. I use publishConfig to point to esm / cjs bundles which overrides exports during the packing and publishing process to npm. This technique has been popularized by colinhacks (Zod author): https://colinhacks.com/essays/live-types-typescript-monorepo

It would be amazing if the cli could support parsing through publishConfig exports.

timostamm commented 3 months ago

TIL about publishConfig:

This is a set of config values that will be used at publish-time.

Unfortunately, it appears that the config values are really only applied when you run npm publish. They are ignored when you run npm pack.

andrewbranch commented 2 months ago

I was leaning towards no, and then...

EDIT: A previous version of this post recommended publishConfig, operating under the mistaken belief that it could be used to override "exports" during npm publish. As it turns out, npm only uses "publishConfig" to override certain .npmrc fields like registry and tag, whereas pnpm has expanded its use to override package metadata like "main", "types", and "exports". There are a number of reasons you may not wish to strongly couple your deployment logic to pnpm (detailed in the publishConfig section below). My updated recommendation is to use a custom export condition plus customConditions in tsconfig.json.

So, yeah. Yikes.