Support Typescript's moduleResolution: "node16"

[amiller-gh]

This is a bug in at least @turf/envelope@6.5.0 and potentially other packages.

Typescript has recently released a new moduleResolution option that when set to node16 or nodenext will use new ESM resolution logic. This includes an understanding of the new "exports" package.json field.

Any module in this monorepo that currently uses the exports field (like @turf/envelope) must now specify the types in the export config as well, otherwise Typescript will complain that it can't find the types file if you turn on moduleResolution: "node16".

E.g. Turn this:

{
  "main": "dist/js/index.js",
  "module": "dist/es/index.js",
  "exports": {
    "./package.json": "./package.json",
    ".": {
      "import": "./dist/es/index.js",
      "require": "./dist/js/index.js"
    }
  },
  "types": "index.d.ts",
}

Into this:

{
  "main": "dist/js/index.js",
  "module": "dist/es/index.js",
  "exports": {
    "./package.json": "./package.json",
    ".": {
      "types": "./index.d.ts",
      "import": "./dist/es/index.js",
      "require": "./dist/js/index.js"
    }
  },
  "types": "index.d.ts",
}

Until then, using this package in Typescript with the new module resolution scheme results in the error TS7016: Could not find a declaration file for module '@turf/envelope'.

[JamesLMilner]

Hey @amiller-gh, I think it's fair to say we're keen to support TypeScript as best we can (we are currently slowly converting Turf modules to TypeScript). This seems reasonably straight forward to resolve - do you have any links to any surrounding information/context? I've looked at the TypeScript page on moduleResolution but I didn't see any mention of the exports fields/types.

[yukha-dw]

+1, seems like TypeScript doesn't know where the typings is when using ES Module.

[nelson6e65]

This seems reasonably straight forward to resolve - do you have any links to any surrounding information/context? I've looked at the TypeScript page on moduleResolution but I didn't see any mention of the exports fields/types.

exports.x.types seems to be a community definition:

"types" - can be used by typing systems to resolve the typing file for the given export. This condition should always be included first.
https://nodejs.org/docs/latest-v16.x/api/packages.html#community-conditions-definitions

Firebase Admin uses it in its exports packaje.json key in addition to types:
https://github.com/firebase/firebase-admin-node/blob/v11.0.1/package.json#L112-L128
https://github.com/firebase/firebase-admin-node/blob/v11.0.1/package.json#L62

AngularFire seems to use typings key instead:
https://github.com/angular/angularfire/blob/7.4.1/package.json#L131

Chalks ES uses only types, but the type definition is in the same directory of the main exports:
https://github.com/chalk/chalk/blob/v5.0.1/package.json#L18

[nelson6e65]

I tried to hard-code my node_modules/@turf/turf/package.json adding types to tests this. It seems to "work", but I got a bunch of "Could not find a declaration file for module '@turf/XXXXX'" errors. 😅

[bonesoul]

import { centerOfMass } from "@turf/turf";

getting the error declaration not found. any solutions?

[deloreyj]

@JamesLMilner the documentation you're looking for to fix this issue is here in the Typescript docs. It should be as simple as adding a types field to the exports

[evgenyt1]

Adding "types": "./index.d.ts" fixes things for me temporarily. But this should be done on @Turf side.

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

[evgenyt1]

I made a PR on this. Pretty straightforward.

[evgenyt1]

I made a temp patch usable through pnpm's patchedDependencies and similar
@turf__turf@6.5.0.patch

[favna]

An alternative patch that will also partially satisfy https://github.com/arethetypeswrong/arethetypeswrong.github.io. I also highly recommend @Turf using ATTW CLI or website to verify that their bundle works properly with both CJS and ESM. Usage is pretty dead simple, see the readme on their repo.

Note that the patch below is a partial satisfaction because officially you're supposed to ship a different types file for CJS as opposed to ESM, i.e. index.d.cts and index.d.ts/index.d.mts. This is related to how for CJS you would likely use export = MyPackage for proper interop with const MyPackage = require('my-package') whereas for ESM you would use export default MyPackage for proper interop with import MyPackage from 'my-package';

I'm also going to summon @Andarist and @andrewbranch here whom are both experts in the field of properly defining ESM/CJS/types and have helped me understand so much about this whole topic.

diff --git a/package.json b/package.json
index 1946d013646f884c74f2d5c7bf94d282154accdc..17cdc18d1858018ea9d41190c7ba53da3788b6d8 100644
--- a/package.json
+++ b/package.json
@@ -48,8 +48,14 @@
   "exports": {
     "./package.json": "./package.json",
     ".": {
-      "import": "./dist/es/index.js",
-      "require": "./dist/js/index.js"
+      "import": {
+        "types": "./index.d.ts",
+        "default": "./dist/es/index.js"
+      },
+      "require": {
+        "types": "./index.d.ts",
+        "default": "./dist/js/index.js"
+      }
     }
   },
   "browser": "turf.min.js",

[Andarist]

The proposed patch above doesn't look correct to me because it tries to reuse the same declaration file for both formats. A single file can only be interpreted either as a module or as a script. You want two files (often even with the same content) so they can independently represent your module (import condition) and your script (require condition). A single file can't be used for both without issues because it's ambiguous. In this particular example, it would be interpreted as a script because this package.json doesn't set "type": "module" so all .js files in this "scope" (and .d.ts runs on the same rules as .js) are treated as scripts.

You could try to copy over your index.d.ts to those es and js directories and point types condition to those copies. This could work because then that /dist/es/index.d.ts would be located in a directory that has an extra package.json in it, one that sets "type": "module". So that would make that .d.ts to be interpreted correctly as a module - whereas the .d.ts in the other directory would continue to represent the script.