Indeed, that’s where it needs to be fixed.

However, for back compat, you should have a file at the location the exports key would otherwise resolve to anyways - so even when it’s fixed in resolve, you’d still want it fixed now.

Will this be resolved any time soon? We're going to have to yank no-unresolved from our Google code samples because it can no longer handle our SDKs.

@inlined why would your Google SDKs be using exports, without main, in a way that's not backwards-compatible??

We are using main. We also use exports for submodule paths so we can omit the lib folder generated by TypeScript.

For example, ./lib/v2/providers/https.js is exported at ./v2/https. See github.com/firebase/firebase-functions for more info.

Right - but that's not backwards-compatible to pre-exports node. However, if you created an actual ./v2/https.js file that re-exported that provider, then not only would your package be backwards-compatible, but you wouldn't be blocked on resolve getting exports support.

We control our execution environment and do not need to be backwards compatible to versions that don't support exports (every supported LTS of Node supports exports). Also, putting a root export would muddy project structure. It is quite common to have a /src and /lib folder for typescript projects. With exports it is quite understandable to remove lib from documented import paths.

@inlined i'm not "of the opinion that exports should not use renaming features", i'm of the opinion that you have a really simple workaround while you wait.

None of my "opinions" are delaying exports support - the work is difficult and nobody else is doing it, and I have limited time. It will be done eventually.

@inlined if google wants to help make it happen faster, please feel free to visit https://github.com/browserify/resolve?sponsor=1

For what it's worth, here's how I solved this situation for a package of mine.

The import style of the library is:

import { fn } from "mylib/next";
import { fn } from "mylib/express";

I updated my package.json build steps with:

{
    "prepublishOnly": "npm run build && cp next/dist/* next/ && cp express/dist/* express/",
    "postpublish": "rm next/*.d.ts next/*.js next/*.map next/*.mjs && rm express/*.d.ts express/*.js express/*.map express/*.mjs"
}

What this does is make copies of the build output files right before npm publish and remove them right after. A bit hacky but it definitely works and will ensure the package works well even on bundlers not supporting the exports: {} field of package.json.

Thanks to the maintainers of eslint-plugin-import for the very hard work they do.

@vvo you can also .gitignore those files (don't forget to make an .npmignore and unignore them there) and avoid the need to remove them afterwards.

Indeed, but I don't want to see these files in my editor (VSCode), they would still appear as grayed out I guess. But I will still add them to gitignore so they never get published committed.

@vvo gitignore is so they don't get committed; you DO want them published, which means you have to have a .npmignore that duplicates your gitignore but removes the lines that ignore build output.

Thanks updated my comment to add committed. Also, I am using the "files: ["dist", "express", "next"]" setting of npm.

Hi all, FYI I am successfully using this tiny ESLint import resolver to support ESM modules imports via package.json exports map:

https://gist.github.com/danielweck/cd63af8e9a8b3492abacc312af9f28fd

Duplicate issue? #1868

It’s just me, and what’s acceptable is only up to collaborators. I’m going to lock the thread for a bit.

Additionally, hiding comments isn’t silencing anything - that’d be called “deleting comments”. I’m just making them hidden by default so they don’t distract new readers of the issue.