You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Nx will not respect the dependency that bar has on foo, despite the explicit declaration in package.json.
This is reflected in both the Web UI and graph output, as well as he dependencies field for project graph from @nx/devkit.
import{createProjectGraphAsync}from'@nx/devkit';constprojectGraph=awaitcreateProjectGraphAsync();projectGraph.dependencies['bar']// [{ source: 'bar', target: 'npm:foo', type: 'static' }]// The `npm:` prefix indicates an external dependency, despite it being a local dependency
Expected Behavior
When projects depend on each otheir via package.json (pnpm's "workspace:^" specifier is used as an example, but is hardly the limit), Nx should respect that dependency when building the project graph.
That means that the project graph should explicitly call out the dependency as seen the web UI (or a JSON output), and the dependencies field for project graph from @nx/devkit should also declare the project as a local dependency.
Create a project ("foo") that includes an exports field in the package.json. Export any path other than "." (I suspect this issue would also occur if the exports object is empty)
Create a second project ("bar") that depends on the first. This dependency can be via traditional dependencies field
Run nx graph and inspect the apparent lack of dependency of foo from bar.
No explicit failure logs.
Just omission of project as dependency.
Any "failures" would manifest because of tasks being executed out of order and dependencies not being available
Package Manager Version
9.15.2
Operating System
macOS
Linux
Windows
Other (Please specify)
Additional Information
Context is also shared in the issue recreation, which helps demonstrate the fact that this dependency is only omitted when using exports that don't include the "." field.
Repeated here for simplicity:
The logic to declare a dependency as "local" as opposed to "external" is implemented in this line.
However it will also calculate this map (memoized), which exposes the bug:
if(!packageExports||typeofpackageExports==='string'){// no `exports` or it points to a file, which would be the equivalent of// an '.' export, in which case the package name is the entry pointresult[packageName]=project;}else{for(constentryPointofObject.keys(packageExports)){result[join(packageName,entryPoint)]=project;}}
result['foo'] will get written because join('foo', '.') returns foo. result['foobar'] would also work because it lacks an exports field.
Howecer result['bar/bar'] is the result of bar because it only has an export for that path.
But the dependency is checked against 'bar', and therefore appears to be an external dependency.
The text was updated successfully, but these errors were encountered:
Current Behavior
When a project declares an exports field and does not include a
"."
export, it will be ignored as a dependency.e.g.
and
Nx will not respect the dependency that
bar
has onfoo
, despite the explicit declaration in package.json.This is reflected in both the Web UI and graph output, as well as he
dependencies
field for project graph from@nx/devkit
.Expected Behavior
When projects depend on each otheir via package.json (
pnpm
's"workspace:^"
specifier is used as an example, but is hardly the limit), Nx should respect that dependency when building the project graph.That means that the project graph should explicitly call out the dependency as seen the web UI (or a JSON output), and the
dependencies
field for project graph from@nx/devkit
should also declare the project as a local dependency.e.g. for example
bar
's dependency onfoo
aboveGitHub Repo
https://github.com/JacobLey/issue-recreator/tree/nx-exports-dependency
Steps to Reproduce
"."
(I suspect this issue would also occur if the exports object is empty)dependencies
fieldnx graph
and inspect the apparent lack of dependency of foo from bar.Nx Report
Failure Logs
No explicit failure logs. Just omission of project as dependency. Any "failures" would manifest because of tasks being executed out of order and dependencies not being available
Package Manager Version
9.15.2
Operating System
Additional Information
Context is also shared in the issue recreation, which helps demonstrate the fact that this dependency is only omitted when using
exports
that don't include the"."
field.Repeated here for simplicity:
The logic to declare a dependency as "local" as opposed to "external" is implemented in this line.
The implementation logic for this method is fairly straightforward.
If the name of the project exists in the map, return in it
However it will also calculate this map (memoized), which exposes the bug:
result['foo']
will get written becausejoin('foo', '.')
returnsfoo
.result['foobar']
would also work because it lacks an exports field.Howecer
result['bar/bar']
is the result of bar because it only has an export for that path.But the dependency is checked against
'bar'
, and therefore appears to be an external dependency.The text was updated successfully, but these errors were encountered: