Surprising (or incorrect) priorities with package.json exports fields?

[DanielRosenwasser]

I'm trying a scenario of module: nodenext with Vue.js. I hit a few issues with resolution of declaration files.

Here's the current Vue.js declarations package.json:

{
    "name": "vue",
    "version": "3.2.20",
    "description": "The progressive JavaScript framework for buiding modern web UI.",
    "main": "index.js",
    "module": "dist/vue.runtime.esm-bundler.js",
    "types": "dist/vue.d.ts",
    // ...
    "exports": {
      ".": {
        "import": {
          "node": "./index.mjs",
          "default": "./dist/vue.runtime.esm-bundler.js"
        },
        "require": "./index.js"
      },
      // ...
      "./package.json": "./package.json"
    }
    // ...
}

However, referencing this in a project results in the following error:

import * as Vue from "vue";
//                   ~~~~~
// error
// Could not find a declaration file for module 'vue'. 'USER_DIR/hackathon/vue-proj/node_modules/vue/index.js' implicitly has an 'any' type.
//  Try `npm i --save-dev @types/vue` if it exists or add a new declaration (.d.ts) file containing `declare module 'vue';`

This kind of makes sense - I think you could argue that this isn't configured right for moduleResolution: node12 or later.

I was able to get this working by adding

 "exports": {
     ".": {
     "import": {
         "node": "./index.mjs",
         "default": "./dist/vue.runtime.esm-bundler.js"
     },
     "require": "./index.js",
+    "types": "./dist/vue.d.ts"
     },
 }

But the following DID NOT work.

 "exports": {
     ".": {
     "import": {
         "node": "./index.mjs",
         "default": "./dist/vue.runtime.esm-bundler.js"
+        "types": "./dist/vue.d.ts"
     },
     "require": "./index.js",
     },
 }

That part seems like a bug, right?

[andrewbranch]

This kind of makes sense - I think you could argue that this isn't configured right for moduleResolution: node12 or later.

My assumption was that a top-level types should merge with the . of an export map in order to continue offering typing support for the top-level import of all existing libraries that are already using export maps. I logged this at #46281.

[weswigham]

That part seems like a bug, right?

Nope. Is the referencing file cjs mode or is esm mode? An import condition is only going to be applicable for an esm mode import - so a cjs mode import (eg, an import in a js file in a package without type:module) isn't going to use the import condition for its imports - it uses the require condition instead.

[weswigham]

My assumption was that a top-level types should merge with the . of an export map in order to continue offering typing support for the top-level import of all existing libraries that are already using export maps. I logged this at #46281.

types is a TS-specific main, which exports blocks - I don't see why it shouldn't also block types.

[andrewbranch]

Is the referencing file cjs mode or is esm mode?

I missed that the package.json didn’t have "type": "module". @DanielRosenwasser what was the file extension of the importing file?

[DanielRosenwasser]

I was importing from a module (.ts file with "type": "module").

[DanielRosenwasser]

types is a TS-specific main, which exports blocks - I don't see why it shouldn't also block types.

I think this is fair, but it highlights 3 things to me

1. We should really give a more accurate error message

   "A 'types' field was found in this package's 'package.json', but was not used because an 'exports' field was found and took priority over the top-level 'main' and 'types' field."

   Probably needs to be word-smithed, but I think it would be helpful.

2. We need to be cautious in our messaging - over-eager people will try to use this in regular projects, and existing packages aren't ready to accommodate them.

3. We probably should help package authors get ready for node12+ resolution modes.

[DanielRosenwasser]

In any case, it's a bug that this one didn't work, right?

 "exports": {
     ".": {
     "import": {
         "node": "./index.mjs",
         "default": "./dist/vue.runtime.esm-bundler.js"
+        "types": "./dist/vue.d.ts"
     },
     "require": "./index.js",
     },
 }

[weswigham]

default is going to be matched before types, because the default condition is always set, and the object is ordered. (So you probably wanna list the type condition first, since it's not usually set except by TS)

[DanielRosenwasser]

Oof that's really confusing. Shouldn't import take priority over types too though?