Platform is not respected in module resolution about esbuild HOT 3 CLOSED

esbuild should read exports:browser instead of exports:.

You are confusing two separate things. In this context, browser is a condition whereas . is a subpath. The subpath . is necessary because you are importing the package itself (import "ulidx" is treated like import "ulidx/." with the way the algorithm works). I assume you want the subpath . to be resolved using the browser condition.

The node_modules/ulidx/package.json looks like this:

{
  "exports": {
    ".": {
      "import": {
        "types": "./dist/index.d.ts",
        "default": "./dist/node/index.js"
      },
      "require": {
        "types": "./dist/index.d.cts",
        "default": "./dist/node/index.cjs"
      },
      "node": {
        "import": {
          "types": "./dist/index.d.ts",
          "default": "./dist/node/index.js"
        },
        "require": {
          "types": "./dist/index.d.cts",
          "default": "./dist/node/index.cjs"
        }
      },
      "browser": {
        "import": {
          "types": "./dist/index.d.ts",
          "default": "./dist/browser/index.js"
        },
        "require": {
          "types": "./dist/index.d.cts",
          "default": "./dist/browser/index.cjs"
        }
      },
      "worker": {
        "import": {
          "types": "./dist/index.d.ts",
          "default": "./dist/browser/index.js"
        },
        "require": {
          "types": "./dist/index.d.cts",
          "default": "./dist/browser/index.cjs"
        }
      }
    }
  },
  ...
}

There is only one exported subpath (called ".") so esbuild is correct for using it. The package provides five ways to resolve the subpath . in order of priority depending on what conditions are currently active: import, require, node, browser, and worker. However, since all path resolutions will either be an import statement or a require call, only the first two path resolutions will ever be used. None of the last three path resolutions (node, browser, and worker) will ever be chosen because they all come after both import and require in priority order.

I'm closing this issue because esbuild seems to be working correctly here. The problem here is that the package definition is broken. It looks like the change that broke it is here: perry-mitchell/ulidx#41. I recommend working with the package author to fix their package. I'm not familiar with how the types condition works, but it's possible their package could be made to work by reverting that change and then adding a default condition that goes last and specifies the default behavior for when no other conditions match. Documentation about how conditions work can be found here: https://nodejs.org/api/packages.html#conditional-exports

from esbuild.

I recently just learnt how TypeScript resolves types, so I will put some additional info here.

First of all, in summary of what Evan said, the order of fields in "exports" matters. The first matched condition will take effect (like import > browser in that case).

For TypeScript, the "types" condition in "exports" should always come first. However, in order to make that work, there're 2 other things need to ensure:

• The TypeScript version should be ≥ 4.7.
• The "moduleResolution" is set to "bundler" or "nodenext". This is needed for TypeScript to pick up the "modern" resolution algorithm, i.e. respect the "exports" field. Here's another article that convince you to do this.

from esbuild.

Thanks for info!

I see that someone already reported it in ulidx repository.
I hope it will get resolved soon. Until then I will use custom patch with patch-package.

from esbuild.