-
-
Notifications
You must be signed in to change notification settings - Fork 18
Implement "exports" proposal #72
Conversation
|
Amazing work! I think that we should remove "Support for the "." export as an alias of the main."... this recreates the issue with dual mode. |
|
this repo is two months behind master, you may want to re-open this in nodejs/node |
|
This repo is not behind master. It's updated once per day by a Jenkins job |
|
I've also added some documentation and included a folder mapping feature test. |
| // Loads ./node_modules/es-module-package/src/features/x.js | ||
| ``` | ||
|
|
||
| If a package has no exports, setting `"exports": false` can be used instead of |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this should just be “any non-nullish value is passed through Object.keys to get the export list; any nullish value disables the feature”, because then “false” is just a convention instead of a magic special value.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So:
nullandundefined: Same as{ './': './' }.- Anything else: Normalized as an object (e.g.
Object.assign({}, pkgExports)).
Makes sense!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I’d use { ...pkgExports } but yes, exactly!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think guiding people towards a convention here may still have value. How about adding the following sentence:
This is just a convention that works because
false, just like{}, has no iterable own properties.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed and that text sounds good to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done!
|
Support for |
|
Afaict this now has all the pieces for the upstream PR, with CJS support and general polish / edge case hunting being follow-ups while it's experimental. |
|
I turned this into a PR against core: nodejs/node#28568 Should we close this PR? |
|
@jkrems i thought we were going to remove |
|
@ljharb May be a misunderstanding: What I removed (and there's a test for it not working) is setting the un-postfixed package name export via the |
|
Or rather the actual test is here: https://github.com/nodejs/node/pull/28568/files#diff-3fa3ea8413322c7b78e358f1a6f6e613R26 |
|
Should this be closed at this point? |
This implements the package.json "exports" proposal (https://github.com/jkrems/proposal-pkg-exports/) with the following features:
"exports"are defined for a package ({ "exports": { "./x": "./x.js" }), resolving that packageimport 'pkg/x', will resolve the exports path (/path/to/pkg/x.js)."exports", an error is thrown (see test case)."exports": falseto indicate a package has no exports at all."."export as an alias of the main.{ "./folder/": "./other-folder/" })Support for
"exports"when resolving from CommonJS is not currently implemented.Checklist
make -j4 test(UNIX), orvcbuild test(Windows) passes