javascript and typescript: "conditions" configuration setting for conditional export resolution in package.json

[vveisard]

I want vscode to resolve a "vscode" condition for conditional exports in my package.json. My use case is to resolve my TypeScript module, so that I can use "Go to" actions without having to bundle my code/ generate a source map.

Alternatively, vscode could add a setting for user conditions, like node.js does: https://nodejs.org/api/packages.html#resolving-user-conditions.

[jrieken]

I want vscode to resolve a "vscode" condition for conditional exports in my package.json. My use case is to resolve my TypeScript module, so that I can use "Go to" actions without having to bundle my code/ generate a source map

Sorry but I don't fully understand what this means. Do you want conditional resolving of the vscode-module, e.g so that its import resolves to something else under some conditions?

[vveisard]

I want vscode to resolve a "vscode" condition for conditional exports in my package.json. My use case is to resolve my TypeScript module, so that I can use "Go to" actions without having to bundle my code/ generate a source map

Sorry but I don't fully understand what this means. Do you want conditional resolving of the vscode-module, e.g so that its import resolves to something else under some conditions?

No, I want to VSCode to resolve JavaScript modules using a "vscode" conditional export in package.json: https://nodejs.org/api/packages.html#conditional-exports

Actually now that I think about it, it would be even better if I could fully configure which conditions VSCode uses to resolve conditional exports, like node.js does using the --conditions flag: https://nodejs.org/api/cli.html#-c-condition---conditionscondition

[VSCodeTriageBot]

Hey @jrieken, this issue might need further attention.

@vveisard, you can help us out by closing this issue if the problem no longer exists, or adding more information.

[vveisard]

Hey, just mentioning this problem still exists.

[rhwinter]

Hi, has anyone found a solution or workaround for this issue?

To give some more context, if one has referenced modules in a workspace where the package.json contains anything like:

{
  "name": "@workspace/module",
  ...
  "exports": {
      ".": {
          "dev": "./index.js",
          "import": "./dist/index.js"
      }
  }
  ...
}

(Notice the dev key, defining a conditional export.)

Suppose you have some file in the same workspace, someFile.js importing that module:

import something from '@workspace/module';

The module resolution will change when node is invoked with the conditions flag:

• node --conditions=dev index.js will resolve @workspace/module from the ./index.js file
• node index.js will resolve @workspace/module from the ./dist/index.js file

But the /dist/ files are only generated when the module is actually built (that is, only in production), so VSCode doesn't seem to be able to autocomplete anything from @workspace/module (the files it looks for don't exist).

It is possible to make auto-completion work by adding a hacky default to the end of exports in package.json, which would look like so:

{
  "name": "@workspace/module",
  ...
  "exports": {
      ".": {
          "dev": "./index.js",
          "import": "./dist/index.js",
+         "default": "./index.js"
      }
  }
  ...
}

But that solution is not ideal: not only does it pollute the package.json files for the sake of the specific editor being used, it can also create other errors if the package is used without being very careful about this export caveat.

Any help or pointers to resolve this are highly appreciated.

[vveisard]

That default export hack only works when the dist files do not exist.

I still haven't found any way around this issue.

[dpnova]

Just stumbled on this issue myself and am wondering how it's not getting more attention haha.

FWIW it also seems to impact decls in the imports field in package json

To ad more signal to @vveisard's comment about default/dist: in my case it was caused by a file in dist that had since been removed in src. VSCode didn't error on the file missing because it was happy to look in dist as the default condition. tsx --conditions=development accurately errored out.

[romanstetsyk]

I just came across this issue and am a little disappointed it's not supported yet. The --conditions CLI option is still experimental, so I have no complaints!

It looks like the only workaround for the exports field is to generate source maps, but this is not as flexible as conditions.

For the imports, it's easier since you can map the desired paths by using the compilerOptions.paths in tsconfig.json.

I hope this feature gets more attention, though.

[dpnova]

@romanstetsyk the beauty of --conditions is it lets you remove all paths configs from tsconfig files. Then use #whatever/foo for imports and lean on tsconfig references for resolution of other @bar/smth packages in a monorepo.

Then exports with conditions obs means you don't have have to delete dist every time you build.

Removing paths and all the associated compatibility packages for jest/vitest etc was a very satisfying thing to do :D

[romanstetsyk]

@dpnova, you're absolutely correct. Having it in vscode would simplify things a lot!