`no-unresolved` is not aware of `exports` definition in `package.json`

[ignatiusreza]

From this announcement

Package entry points and the package.json “exports” field

There are now two fields that can define entry points for a package: “main” and“exports”. The “main” field is supported in all versions of Node.js, but its capabilities are limited: it only defines the main entry point of the package. A new package.json field “exports” can also define the main entry point, along with subpaths. It also provides encapsulation, where only the paths explicitly defined in “exports” are available for importing. “exports” applies to both CommonJS and ES module packages, whether used via require or import.

Might need to be fix in resolve package..

[ljharb]

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.

[inlined]

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.

[ljharb]

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

[inlined]

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.

[ljharb]

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.

[inlined]

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.

[ljharb]

@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.

[ljharb]

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