Evaluate popular packages that have exports fields set but may not be Node ESM-ready for TypeScript

[DanielRosenwasser]

The exports field in package.json - nobody knows how to configure it, which probably means that a negative number of people know how to configure it for TypeScript.

Anyway, a very good way to ensure that 99% of users have no issues with consuming a Node ESM package is to do a sweep of the npm registry to find the most popular packages that have an exports field and a types field set and validate that they have correctly configured their types.

The steps include

• Generating the list of 150 of the top-depended-on packages that have an rts field and have either a types field set or have a corresponding @types package.
• Distributing out the list to the team.
• Having the team manually validate that the packages (or their @types package) are configured correctly.

Last time I tried to do this with all-the-package-names, people told me the list might be too outdated, but the list might serve as a decent guide anyway:

Click here to see the list.

Self-Typed: 18

Package Name	Exports Value	Assesment
postcss	Object	?
babel-jest	Object	?
rxjs	Object	?
typedoc	String	?
ts-node	Object	?
projectz	Object	?
postcss-custom-properties	Object	?
postcss-scss	Object	?
uid	Object	?
emailjs	Object	?
ngrok	Object	?
pob-babel	Object	?
preact	Object	?
assert-helpers	Object	?
getmac	Object	?
simple-statistics	Object	?
discord.js	Object	?
editions	Object	?

Packages with @types

At-Typed: 121

Package Name	Exports Value	Assesment
chai	Object	?
eslint	Object	?
tape	Object	?
underscore	Object	?
yargs	Object	?
socket.io	Object	?
js-yaml	Object	?
expect	Object	?
uuid	Object	?
ws	Object	?
rollup	Object	?
koa	Object	?
socket.io-client	Object	?
meow	String	?
npm	Object	?
jest-cli	Object	?
highlight.js	Object	?
mustache	Object	?
dotenv	Object	?
d3	Object	?
deep-equal	Object	?
jest	Object	?
gulp-imagemin	String	?
diff	Object	?
unique-random-array	String	?
globby	String	?
ora	String	?
acorn	Object	?
path-exists	String	?
firebase	Object	?
vinyl-paths	String	?
strip-ansi	String	?
strip-json-comments	String	?
systemjs	Object	?
log-symbols	Object	?
escape-string-regexp	String	?
get-stdin	String	?
stack-trace	Object	?
is-promise	Object	?
slash	String	?
es6-promisify	Object	?
imagemin	String	?
configstore	String	?
figures	String	?
strip-bom	String	?
mathjs	Object	?
baconjs	Object	?
engine.io	Object	?
is-plain-object	Object	?
tempfile	String	?
arrify	String	?
supports-color	Object	?
tildify	String	?
is-stream	String	?
normalize-url	String	?
d3-scale	Object	?
temp-write	String	?
indent-string	String	?
d3-selection	Object	?
d3-array	Object	?
read-chunk	String	?
is-plain-obj	String	?
yaml	Object	?
engine.io-client	Object	?
js-cookie	Object	?
ansi-styles	String	?
npm-name	String	?
pako	Object	?
detect-indent	String	?
decamelize	String	?
stringify-object	String	?
ansi-regex	String	?
sass	Object	?
string-length	String	?
get-port	String	?
lowdb	String	?
js-base64	Object	?
find-up	String	?
dargs	String	?
array-uniq	String	?
humanize-url	String	?
repeating	String	?
d3-shape	Object	?
read-pkg-up	String	?
strip-indent	String	?
hashids	Object	?
junk	String	?
istextorbinary	Object	?
ansi-escapes	String	?
geolib	Object	?
yargs-parser	Object	?
commonmark	Object	?
username	String	?
jssha	Object	?
latest-version	String	?
github-username	String	?
string-width	String	?
is-root	String	?
d3-transition	Object	?
trash	String	?
js-combinatorics	Object	?
socket.io-parser	Object	?
d3-dsv	Object	?
form-urlencoded	Object	?
semver-regex	String	?
cli-cursor	String	?
internal-ip	Object	?
linq	String	?
d3-color	Object	?
node-hue-api	Object	?
d3-interpolate	Object	?
elegant-spinner	String	?
read-pkg	String	?
has-ansi	String	?
node-ipc	Object	?
leven	String	?
d3-axis	Object	?
d3-format	Object	?
is-obj	String	?
boxen	String	?
d3-dispatch	Object	?

[andrewbranch]

all-the-package-names seems to be updated daily. Not sure why we thought the list was outdated before?

[jaydenseric]

I've been using TypeScript v4.6-dev.x and the node12 mode extensively for some time now. One of the things that makes it really confusing to work with the new node12 mode is that often VS Code lies and is able to display types for imports ok within the editor (yes, with the local TypeScript installation selected in VS Code), when really tsc via the CLI can't resolve the types. You will see "has no exported member" type errors for the same imports, when the imported package doesn't support TypeScript v4.6 node12 mode properly with correct package exports, .d.mts files, etc.

It makes it harder to evaluate as you are working what packages are ESM ready and to experiment with possible fixes for a PR by hacking them in node_modules, since you have to ignore what the editor is saying and keep running the tsc CLI for feedback.

An example of a package this happens with is [email protected]...

With this .vscode/settings.json:

{
  "typescript.disableAutomaticTypeAcquisition": true,
  "typescript.enablePromptUseWorkspaceTsdk": true,
  "typescript.tsdk": "node_modules/typescript/lib"
}

And this jsconfig.json:

{
  "compilerOptions": {
    "module": "node12",
    "noEmit": true,
    "strict": true
  },
  "typeAcquisition": {
    "enable": false
  }
}

And this package devDependency:

{
  "typescript": "^4.6.0-dev.20220207"
}

And this package scripts:

{
  "types": "tsc -p jsconfig.json",
}

If you run:

npm run types

In a.mjs:

// @ts-check

/** @typedef {import("playwright").chromium} A */
/** @typedef {import("playwright").Page} B */

In b.mts:

import { chromium } from "playwright";
import type { Page } from "playwright";

In the VS Code editor the imported Page type resolves for intellisense:

But via tsc:

The playwright package doesn't appear to be in the list of "popular" packages for this issue, but given it's pretty popular and also a Microsoft project that aims to support TypeScript it would really make sense for it to be fully compatible with TypeScript v4.6.

[weyert]

@DanielRosenwasser Would you be so kind and help me find the correct way to do?
Would the snippet below be correct?

"exports": {
    ".": {
      "import": "./index.mjs",
      "require": "./index.js",
      "types": "./index.d.ts"
    },
    "./cli": "./cli.js",
    "./package.json": "./package.json",
  },

Assuming there is a index.d.ts in the root of the package directory

[andrewbranch]

That is right, assuming a single index.d.ts can accurately describe the ESM and CJS interfaces simultaneously.

[sandersn]

all-the-package-names seems to be updated daily. Not sure why we thought the list was outdated before?

It wasn't published for two years, then the first publish was 10 hours before your comment. Coincidence?

..Probably.

Edit: looking at nice-registry/all-the-package-names#26, I see that it now depends on all-the-package-repos, which now, surprisingly, includes all packages, even ones without repos. But it's not sorted by dependent count anymore.

Edit 2 (from May): all-the-package-names stopped updating from mid-March to May. Check to see if it's current before using it.

[lizthegrey]

This appears to be impacting Jose and Terser where types export is not configured, but types are available and listed in package.json

[DanielRosenwasser]

Thank you for sending those PRs!

[lizthegrey]

This just bit vue-router.