Support alternatives in package.json exports

[leeweisberger]

Most build systems support a list of options in the exports field in the package.json. Here's the documentation from webpack.

Screenshot from attached link:

My specific usecase is that I am trying to esbuild a yarn workspace. Packages in the workspace refer to other workspace packages. My production-build pipeline produces some new files that don't exist before running the build pipeline. I am unable to esbuild my workspace without generating these files. If I could use alternatives, I could support esbuilding my workspace without generating my production artifacts.

[evanw]

The reason esbuild does it this way is because that's the way exports is specified: https://nodejs.org/api/esm.html#resolver-algorithm-specification, so that's how it's supposed to work. What you are requesting would be a deviation from the specification. I'll consider trying to support this but it'll probably involve a good amount of research and reverse-engineering to figure out which other tools do this and specifically what they do.

[Thristhart]

I have a bunch of packages in a monorepo that are disributed as typescript, with a mix of .ts and .tsx extensions. I don't want consumers to have to specify extensions when importing, and I want only the src folder to be imported, so these packages have something like this in their package.jsons:

	"exports": {
		"./*": [
			"./src/*.ts",
			"./src/*.tsx",
			"./src/*"
		]
	},

This gets the behavior to what you'd expect from importing from a file in the same package, where .ts and .tsx are both implicit extensions. i.e. import foo from "@scope/foo" works like import foo from "./foo". Without this, if I did something like:

	"exports": {
		"./*": "./src/*"
	},

Consumers would have to import with the full extension (import foo from "@scope/foo.tsx") which is inconsistent with how they import everywhere else.

The approach I'm using works great in typescript, and as discussed works in webpack. In this context it feels weird that esbuild doesn't match typescript's behavior, since I'm entirely working with typescript files, but I understand that typescript isn't matching the spec here.

Is there a spec-compliant way I can accomplish this with esbuild? My current plan is to work around this by writing a resolver plugin but I'd love to do this in a more blessed way if it exists.

[chrisandrewcl]

Looking forward to this one. My use case:

  "exports": {
    "./*": [
      "./src/*/index.ts",
      "./src/*.ts"
    ]
  },

This way both cases below will work:

import { aModuleIndex } from "mydep/module"
import { aModuleFile } from "mydep/module/file"

[chrisandrewcl]

Also, if this is being considered, the package.json imports have the same issue. It would be great to have alternatives working for both of them.

[evanw]

Looks like Webpack is changing their non-standard behavior to align with node: webpack/enhanced-resolve#400 and webpack/enhanced-resolve#429. I'm closing this issue because without Webpack, there isn't a strong case for diverging from the specification for this IMO.