Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
ignatiusreza opened this issue Jun 8, 2020 · 71 comments
Open

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

ignatiusreza opened this issue Jun 8, 2020 · 71 comments

Comments

@ignatiusreza
Copy link

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
Copy link
Member

ljharb commented Jun 8, 2020

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
Copy link

inlined commented Aug 5, 2021

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
Copy link
Member

ljharb commented Aug 5, 2021

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

@inlined
Copy link

inlined commented Aug 5, 2021

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
Copy link
Member

ljharb commented Aug 5, 2021

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
Copy link

inlined commented Aug 5, 2021

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 added a commit to firebase/firebase-tools that referenced this issue Aug 6, 2021
The import module does not currenty handle package exports.
The author is apparently of the opinion that exports should not
use renaming features. Until this is fixed, all of the v2
API is broken.

See import-js/eslint-plugin-import#1810
for more info.
inlined added a commit to firebase/firebase-tools that referenced this issue Aug 6, 2021
The import module does not currenty handle package exports.
The author is apparently of the opinion that exports should not
use renaming features. Until this is fixed, all of the v2
API is broken.

See import-js/eslint-plugin-import#1810
for more info.
@ljharb
Copy link
Member

ljharb commented Aug 6, 2021

@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
Copy link
Member

ljharb commented Aug 6, 2021

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

inlined added a commit to firebase/firebase-tools that referenced this issue Aug 6, 2021
* Print function names on validation errors, not [Object object]

* Require all necessary APIs

* Remove import eslint module

The import module does not currenty handle package exports.
The author is apparently of the opinion that exports should not
use renaming features. Until this is fixed, all of the v2
API is broken.

See import-js/eslint-plugin-import#1810
for more info.

* Linter fixes
@vvo
Copy link

vvo commented Oct 28, 2021

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.

@ljharb
Copy link
Member

ljharb commented Oct 28, 2021

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

@vvo
Copy link

vvo commented Oct 28, 2021

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.

@ljharb
Copy link
Member

ljharb commented Oct 28, 2021

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

@vvo
Copy link

vvo commented Oct 28, 2021

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

devpeerapong pushed a commit to devpeerapong/firebase-tools that referenced this issue Dec 14, 2021
* Print function names on validation errors, not [Object object]

* Require all necessary APIs

* Remove import eslint module

The import module does not currenty handle package exports.
The author is apparently of the opinion that exports should not
use renaming features. Until this is fixed, all of the v2
API is broken.

See import-js/eslint-plugin-import#1810
for more info.

* Linter fixes
@danielweck
Copy link

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

@conartist6

This comment was marked as off-topic.

@ljharb

This comment was marked as off-topic.

@conartist6

This comment was marked as off-topic.

@conartist6

This comment was marked as off-topic.

@conartist6

This comment was marked as off-topic.

@ljharb

This comment was marked as off-topic.

@conartist6

This comment was marked as off-topic.

@ljharb

This comment was marked as off-topic.

@conartist6

This comment was marked as resolved.

@ljharb

This comment was marked as resolved.

@piranna

This comment was marked as abuse.

@conartist6

This comment was marked as off-topic.

@ljharb

This comment was marked as resolved.

@ljharb

This comment was marked as off-topic.

@conartist6

This comment was marked as off-topic.

@conartist6

This comment was marked as off-topic.

@ljharb

This comment was marked as off-topic.

@conartist6

This comment was marked as resolved.

@ljharb

This comment was marked as resolved.

@conartist6

This comment was marked as resolved.

@ljharb

This comment was marked as off-topic.

@conartist6

This comment was marked as outdated.

@ljharb

This comment was marked as outdated.

@conartist6

This comment was marked as outdated.

@ljharb

This comment was marked as outdated.

@conartist6

This comment was marked as off-topic.

@conartist6

This comment was marked as off-topic.

@conartist6

This comment was marked as off-topic.

@ljharb
Copy link
Member

ljharb commented Nov 19, 2023

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.

@import-js import-js locked as too heated and limited conversation to collaborators Nov 19, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Development

No branches or pull requests