-
Notifications
You must be signed in to change notification settings - Fork 146
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
Exports support, dynamic import from CJS support, package boundary emission #129
Conversation
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.
Co-authored-by: Steven <steven@ceriously.com>
@styfle I've implemented an alternative that separates The default behaviour now will trace both exports and the main. Setting exports allows changing the list of exports conditions that are traced. Then setting |
The remaining windows failures here are pretty odd - I can't replicate them on my Windows machine running the same Node.js version... |
Finally traced the issue... this should be good to merge. |
@guybedford This doesn't work with For example:
I would expect Can we add an integration test for |
Nicely spotted, ok I've added the integration test and also included a unit test for the array fallback case. |
package.json
Outdated
@@ -26,6 +26,7 @@ | |||
"acorn-numeric-separator": "^0.3.0", | |||
"acorn-static-class-features": "^0.2.1", | |||
"bindings": "^1.4.0", | |||
"es-get-iterator": "^1.1.0", |
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.
Should be devDependencies
and the version number should be pinned 🙂
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.
We're not currently pinning any versions in this repo! I forget that's the preferred pattern, let's get a separate PR up for that.
src/resolve-dependency.js
Outdated
@@ -90,11 +90,14 @@ function getExportsTarget (exports, conditions, cjsResolve) { | |||
condition === 'import' && !cjsResolve || | |||
conditions.includes(condition)) { | |||
const target = getExportsTarget(exports[condition], conditions, cjsResolve); | |||
if (target !== undefined) | |||
if (target !== undefined && (target === null || target.startsWith('./'))) |
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.
Is it expected that this if
statement does not match the one on line 82 above?
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.
Yes they should be the same - fixed.
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.
@guybedford They are a little different still. Why use continue
with one and not the other?
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.
Right, they are written differently but do the same thing. So the definition of the array fallback is that it will continue on invalid items, which is supposed to be different from the object conditions form. But I just realise now we're not actually doing that either! Done.
Note the extreme exports edge cases get pretty complex but aren't needed in 99% of cases... so we are just rattling out the "exports": [{}, { "asdf": null }, null]
kinds of odd behaviours here.
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.
@guybedford I don't see a test for the array of exports
like you mentioned above? They are all object exports
as far as I see. Can we add a test for array?
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.
Yes there is a test at https://github.com/vercel/node-file-trace/pull/129/files#diff-fb129c0544238468b2fbaf801b451a7f for the fallback support.
Co-authored-by: Steven <steven@ceriously.com>
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.
Great work!
"test/unit/yarn-workspaces/input.js", | ||
"test/unit/yarn-workspaces/node_modules/x", | ||
"test/unit/yarn-workspaces/node_modules/x/package.json", |
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.
@guybedford I think this file was incorrectly emitted since this line is a symlink pointing to the last line in the output here. See PR #135 for the fix.
PR #129 emits `package.json` files but it should not be emit if package.json is inside a symlinked directory. This is a common pattern for yarn workspaces. This PR fixes yarn workspaces and adds a new test for yarn workspaces using ESM imports/exports. Co-authored-by: Guy Bedford <guybedford@gmail.com>
This PR fixes a bug where TS input was not considering ESM with `type: module` in package.json Related to #129 which added package.json emission but only for JS input.
This PR implements three new features
exports
field as per Node.js, including conditional exports and package name self-resolutionExports support is by default disabled, and enabled by setting the
exports: true
option or providing a custom condition list.For example, if building for Node.js 10, you'd want the exports support to be disabled since the
"main"
resolution would still apply - which would not be traced if enabling exports (when exports overrides it).