Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
fix: enable compatibility with node16/nodenext module resolution
TypeScript's `node16` and `nodenext` module resolution algorithms attempt to adhere more closely to the behavior of the `exports` field. To that end, if an `exports` field is present in a package, the `types` field is ignored; instead, a `types` conditional export is expected. Without this change, any consumer using one of these newer--_officially recommended_--module resolution algorithms will be unable to load any `types.d.ts` file from any package. We retain the `types` field because of backwards compatibility with the legacy `node` module resolution algorithm. ### Should `types.d.ts` exist at all? _It depends._ While this file is not _truly_ needed for type support if type declarations are shipped alongside each `.js` source file, it's awkward to export any types created via `@typedef` without it. For instance, say we have a function `foo(opts: FooOpts)`. `foo` lives in `a.js`, and `FooOpts` is a `@typedef` in `b.js`. The parameter `opts` is tagged as `@param {import('./b.js').FooOpts} opts`, as it should. Entry point `index.js` re-exports `foo()` from `a.js`. However, the definition for `FooOpts` _will not be available to consumers_--which will cause compilation errors. We must, then, re-export this type from the entry point. To avoid this, we have precious few tools at our disposal: 1. Create a reference of `FooOpts` in `index.js` via `@typedef`, which will export the `FooOpts` type. If `FooOpts` is generic, this becomes more of a headache, as we have to _copy_ the generics from the original. This is a hazard, because the generics could become out-of-sync. 2. Create a `.d.ts` (it could also be a `.ts`, which we can assume will generate the associated `.d.ts`; this doesn't matter for our purposes) which re-exports `FooOpts` from `b.js`. This file will be the titular `types.d.ts`. The question we need to ask, then, is "do we need to export any `@typedef`s?" If the answer is _yes_, then a `types.d.ts` makes sense. I didn't actually check to see if `types.d.ts` is appropriate in all of these packages; I just fixed the problem I was encountering. For `@endo/compartment-mapper`, some work I'm doing will mean re-exporting some `@typedef`s, even if that's not happening currently. Furthermore, I ignored the packages with `"types": null`, since I don't understand what that's supposed to mean.
- Loading branch information