Intellisense not resolving modules when using `exports` in package.json

[mjbvz]

Reposting from VSCode repo for @magnusriga. I transferred the original issue to the wrong repo and now can't transfer it back

---

Does this issue occur when all extensions are disabled?: Yes

• VS Code Version: 1.84.2
• OS Version: Windows 11 Pro

Steps to Reproduce:

1. Build any project (A) with a dependency on another project (B), where project B's package.json exports files using the exports field
2. Observer how Intellisense does not work
3. Insert the main and types fields and see that Intellisense starts working again

Intellisense Works When main and types are set:

Package B's package.json

Package A's import (notice the Intellisense pop-up. It is possible to ctrl-click the path.)

Intellisense Does Not Work When only exports is set:

Package B's package.json (removed main and types)

Package A's import (not possible to crl+click to find the package, i.e. no Intellisense)

[RyanCavanaugh]

We need an actual repro. Also, please post code, not screenshots of code.

[magnusriga]

I finally got Intellisense to work and respect the exports field.

Here is a working repo: https://github.com/magnusriga/my-turborepo

Leaving my config below in case it is helpful to anyone else. The below is slightly different to the repo above, it uses a src folder in package B.

Package B's package.json (note the exports field and the omission of main)

{
  "name": "@acme/ui",
  "version": "3.0.1",
  "private": true,
  "sideEffects": [
    "**/*.css"
  ],
  "exports": {
    ".": {
      "types": "./types/index.d.ts",
      "import": "./dist/index.js"
    },
    "./*": {
      "types": "./types/*.js",
      "import": "./dist/*.js"
    }
  },
  "scripts": {
    "build": "rimraf dist && tsc -p",
    "clean": "rm -rf dist",
    "dev": "rimraf dist types .Cache && tsc --watch",
    "lint": "eslint src/",
    "test": "jest",
    "check-types": "tsc --noEmit"
  },
  "jest": {
    "preset": "jest-presets/jest/browser"
  },
  "devDependencies": {
    "@babel/preset-react": "latest",
    "@types/react": "latest",
    "@types/react-dom": "latest",
    "@types/styled-components": "latest",
    "autoprefixer": "latest",
    "eslint-config-custom": "workspace:*",
    "fs-extra": "latest",
    "rimraf": "latest",
    "postcss": "latest",
    "react": "latest",
    "tailwind-config": "workspace:*",
    "tailwindcss": "latest",
    "tsconfig": "workspace:*",
    "typescript": "latest",
    "watch": "latest"
  },
  "peerDependencies": {
    "react": "latest",
    "styled-components": "latest"
  }
}

Package A's import

// Intellisense shows only the exported packages when writing the RHS path, which was my goal here
import { Button } from '@acme/ui/components/button';

Package B's tsconfig (the three are chained via extends)

{
  "extends": "tsconfig/react-library.json",
  "compilerOptions": {
    "allowJs": true,
    "declaration": true,
    "noEmit": false,
    "noEmitOnError": true,
    "incremental": true,
    "outDir": "dist",
    "declarationDir": "types",
    "tsBuildInfoFile": ".Cache/tsc.buildinfo.json",
    "rootDir": "src",

    "sourceMap": true,
    "inlineSources": true,
    "sourceRoot": "src",

    "baseUrl": ".",
    "paths": {
      "@/*": ["./src/*"],
      "@components/*": ["src/components/*"],
      "@utils/*": ["src/utils/*"],
      "@lib/*": ["src/lib/*"],
      "@styles/*": ["src/styles/*"],
      "@ui/*": ["src/ui/*"],
      "@context/*": ["src/context/*"],
      "@templates/*": ["src/templates/*"],
      "@public/*": ["public/*"]
    }
  },
  "include": ["./src"],
  "exclude": [
    "dist",
    "build",
    ".Cache",
    "types",
    "node_modules",
    "cypress",
    "test",
    "**/__tests__/*",
    "jest.setup.tsx"
  ]
}

{
  "$schema": "https://json.schemastore.org/tsconfig",
  "display": "React Library",
  "extends": "./base.json",
  "compilerOptions": {
    "jsx": "react-jsx",
  }
}

{
  "$schema": "https://json.schemastore.org/tsconfig",
  "display": "Default",
  "compilerOptions": {
    "esModuleInterop": true,
    "skipLibCheck": true,
    "target": "es2022",
    "resolveJsonModule": true,
    "isolatedModules": true,
    "moduleDetection": "force",
    "strict": true,
    "noUncheckedIndexedAccess": true,
    "moduleResolution": "Bundler",
    "module": "ESNext",
    "noEmit": true,
    "lib": ["es2022", "dom", "dom.iterable"],

    "forceConsistentCasingInFileNames": true,
    "noFallthroughCasesInSwitch": true,
    "noUnusedLocals": false,
    "noUnusedParameters": false,
    "preserveWatchOutput": true
  },
  "exclude": ["node_modules"]
}

[andrewbranch]

@magnusriga can you please provide instructions on how to reproduce the problem in the context of the repo you shared?

[magnusriga]

@andrewbranch I actually got it to work. I posted a working repo above to showcase the settings needed to make it work (in case it is useful to others in the future).

@mjbvz can mark it as resolved (I am unable to, since I am no longer the OP).

[virtuallyunknown]

Hey folks, can this be reopened please? Here is a bare-minimum example:

https://github.com/virtuallyunknown/esm-exports-no-intellisense

To reproduce:

1. clone the repository
2. npm install (important step)

---

The problem can be observed in packages/two/test.js where there is no Intellisense. Why? Because the package we're exporting from - @repo/one does not define a main field and only uses the modern exports variant.

Adding a main field fixes the problem.

{
    "name": "@repo/one",
    "version": "1.0.0",
    "author": "me",
    "type": "module",
+   "main": "./src/index.js",
    "exports": {
        ".": {
            "import": "./src/index.js"
        }
    }
}

Also, apologies if this is not the correct place to ask. My reason to ask here is because I saw this was redirected from the VSCode repo.

[andrewbranch]

@virtuallyunknown this is a known issue regarding the default settings that VS Code passes to TS Server (which powers JavaScript IntelliSense). The current defaults are very forgiving, which is good because we don’t know what kind of project a JS user has without additional config, but they lack support for newer features like package.json "exports". If this is a Node.js project, you can add a jsconfig.json file to your project root like this:

{
  "compilerOptions": {
    "module": "nodenext"
  }
}

[virtuallyunknown]

@andrewbranch thanks for taking your time to explain the issue to me, I really appreciate it.

I have tried the jsconfig.json and it seems to do the trick, so I suppose this is an acceptable workaround for the time being (or alternatively using main field), and if you and/or the vscode team are aware of the issue, then that's great.

In my personal opinion it's important that developers can make use of all ESM features so we can finally move away from CJS and all start using one unified system, but I also understand you guys probably have more pressing issues that require your attention.

Cheers!

[virtuallyunknown]

Hey @andrewbranch sorry to bother you again, but I have a follow-up question.

In my demo (mono)repository we export some files from @repo/one and we import them in @repo/two. Adding jsconfig.json in project root fixes the issue with the imports field, but another issue arises if @repo/two is a typescript project with a tsconfig.json of it's own.

You can see the basic project overview here, and I updated my demo repository as well with a reproducible example, where the same problem as before arises if @repo/two is a typescript project.

.
├── packages
│   ├── one 👉👉👉 export from here
│   │   ├── src
│   │   │   ├── bar.js
│   │   │   ├── foo.js
│   │   │   └── index.js
│   │   └── package.json
│   ├── tsconfig
│   │   ├── src
│   │   │   ├── tsconfig.node.json
│   │   └── package.json
│   └── two 👈👈👈 import here
│       ├── src
│       │   └── dummy.ts
│       ├── package.json
│       ├── test.js
│       └── tsconfig.json ❗❗❗ this is a typescript project now.
├── jsconfig.json
├── package.json
└── package-lock.json

So I guess my question is if there is a similar workaround for this particular problem? One might think to themselves that this is quite a weird setup to have, but my use case is that I put build scripts in the root of each sub-project (where test.js currently is), and my typescript files reside in the src directory.

If all of this is taking too much of your time then no worries, I will work with what I currently have, cheers.

[andrewbranch]

What’s happening here is the presence of the tsconfig.json next to test.js is throwing us off from finding the root jsconfig.json when looking for a config to use for editor support. When you open test.js, we start looking for jsconfig/tsconfig files up the directory spine from that file. We stop when we see the tsconfig.json, but it doesn’t actually include test.js. Instead of continuing the search, it seems like we give up and put test.js in an inferred project with default settings. I don’t know if this is a known limitation or a bug, but it seems like something that could be improved. (cc @sheetalkamat)

I think the most conventional workaround would be to put your scripts in their own directory with their own tsconfig.json/jsconfig.json. Alternatively, you could name your package-level tsconfigs something else (tsconfig.src.json) and reference them from a root-level solution tsconfig.json:

{
  "files": [],
  "references": [
    { "path": "./packages/two/tsconfig.src.json" },
    { "path": "./tsconfig.scripts.json" }
  ]
}

The trick is to make it so that the nearest file named literally tsconfig.json (or jsconfig.json) up from any file actually includes that file somehow, either directly or by fanning out into a referenced project that includes it.

[magnusriga]

@andrewbranch Thanks for the awesome support here. I made a change to my repo and now have issues again. If you have time, could you check out my last comment in this PR: vercel/turborepo#6575

Long story short, Turbo's example is a monorepo with, among others, a next.js package and a @repo/package/ui (only supports TS). The maintainer claims that IntelliSense (auto-import) does not work if we use a catch-all ("./*": "./src/*.tsx") in the exports, due to a TypeScript bug. Is that right?

Also, I got it to work if I used a conditional export, any idea why that is? I.e. what is the difference between these:

Works:

  "./*": {
     "import": "./src/*.tsx"
  }

Does not work:

  "./*": "./src/*.tsx"

Lastly, is there a way for IntelliSense to support both TS and JS files? These did not work:

1)

  "./*.tsx": {
     "import": "./src/*.tsx"
  },
  "./*.js": {
     "import": "./src/*.js"
  }

2)

  "./*": {
     "import": "./src/*"
  }

[andrewbranch]

Also, I got it to work if I used a conditional export, any idea why that is? I.e. what is the difference between these

That sounds like a bug. Can you provide a specific repro?

Lastly, is there a way for IntelliSense to support both TS and JS files? These did not work

It’s hard to tell exactly what the intent is here without a repro, but something that seems relevant is file extension substitution. Any time TS sees a request to resolve a file ending in .js, it actually tries to resolve .ts, .tsx, and .d.ts at a higher priority, because if one of those exists, it’s assumed to be the source of the .js file (or typed artifact, in the case of .d.ts).

[virtuallyunknown]

We stop when we see the tsconfig.json, but it doesn’t actually include test.js. Instead of continuing the search, it seems like we give up and put test.js in an inferred project with default settings.

I have actually tried manually including the test.js file in the include field of the tsconfig.json file that sits in the same directory next to it, and naively I thought that might do the trick, but unfortunately it didn't.

{
    "extends": ["@repo/tsconfig/tsconfig.node.json"],
    "include": ["./src/", "./test.js"],
    "exclude": ["**/node_modules", "**/.*/"]
}

Another thing I tested just now is having both jsconfigs and tsconfigs next to one another in a package-level directory, but to no avail either (probably because tsconfig takes precedence as you suggested). The explanation you provided makes sense of what is happening, and one of the workarounds of having the scripts in their own directory with a dedicated jsconfig.json seems to fix the issue. But my use case here is that these plain javascript files are responsible for building/compiling the src directory, so all relative paths would become a mess and at this point all of this is way more trouble than it is worth.

I think at this point the best/most sane way to move forward is to keep an exports field for future compatibility and a main field to keep VSCode/TS Server happy for the time being until hopefully this is fixed or improved in some future release.

So yeah, I think I am leaving it like that for the moment, and thanks again for being so helpful, I also learned a thing or two about the way this works which can be useful knowledge in the future :)