-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
NX Packages without default export are excluded from dependencies #29486
Comments
Issue originally discovered because a local plugin for my Nx repo suddenly stopped being picked up as a dependency, resulting in failures. My workaround was to declare a ".": "https://github.com/nrwl/nx/issues/29486" export |
Issue arose between Most likely aligning with creation of file |
Similar bug when export is define like that: then in: the packages that import it doesn't recognize as depend on that package. |
#29577) Sibling dependencies that rely exclusively on subpath exports are excluded from the dependency graph because there is no exact match. This adds a fallback to look for subpath exports if the exact match is not found. This also adds logic to respect conditional exports independent from subpath exports. <!-- Please make sure you have read the submission guidelines before posting an PR --> <!-- https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr --> <!-- Please make sure that your commit message follows our format --> <!-- Example: `fix(nx): must begin with lowercase` --> <!-- If this is a particularly complex change or feature addition, you can request a dedicated Nx release for this pull request branch. Mention someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they will confirm if the PR warrants its own release for testing purposes, and generate it for you if appropriate. --> ## Current Behavior Importing a workspace dependency via subpath export fails to match the package name, and so is not included in the dependency graph. ### Example ```apps/api/package.json``` ```json "name": "@my-org/api", "dependencies": { "@my-org/services": "workspace:*" } ``` ```libs/services/package.json``` ```json "name": "@my-org/services", "exports": { "./email": "./dist/email.js" } ``` The `@my-org/api` app should be able to import the email service with `import { EmailService } from "@my-org/services/email"`. However, the `getPackageEntryPointsToProjectMap` implementation results in an object with a key of `@my-org/services/email`, but not `@my-org/services`. This is not specifically a problem, except that `findDependencyInWorkspaceProjects` only considers exact matches within those object keys. ## Expected Behavior Importing a workspace dependency via subpath export should be included in the dependency graph. I also addressed a related issue where the following resulted in keys of `@my-org/services/default` and `@my-org/services/types`, which is incorrect according to the subpath/conditional export rules. ```json "exports": { "default": "./dist/index.js", "types": "./dist/index.d.ts" } ``` ## Related Issue(s) <!-- Please link the issue being fixed so it gets closed when this is merged. --> Fixes #29486 --------- Co-authored-by: Leosvel Pérez Espinosa <[email protected]>
#29577) Sibling dependencies that rely exclusively on subpath exports are excluded from the dependency graph because there is no exact match. This adds a fallback to look for subpath exports if the exact match is not found. This also adds logic to respect conditional exports independent from subpath exports. <!-- Please make sure you have read the submission guidelines before posting an PR --> <!-- https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr --> <!-- Please make sure that your commit message follows our format --> <!-- Example: `fix(nx): must begin with lowercase` --> <!-- If this is a particularly complex change or feature addition, you can request a dedicated Nx release for this pull request branch. Mention someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they will confirm if the PR warrants its own release for testing purposes, and generate it for you if appropriate. --> ## Current Behavior Importing a workspace dependency via subpath export fails to match the package name, and so is not included in the dependency graph. ### Example ```apps/api/package.json``` ```json "name": "@my-org/api", "dependencies": { "@my-org/services": "workspace:*" } ``` ```libs/services/package.json``` ```json "name": "@my-org/services", "exports": { "./email": "./dist/email.js" } ``` The `@my-org/api` app should be able to import the email service with `import { EmailService } from "@my-org/services/email"`. However, the `getPackageEntryPointsToProjectMap` implementation results in an object with a key of `@my-org/services/email`, but not `@my-org/services`. This is not specifically a problem, except that `findDependencyInWorkspaceProjects` only considers exact matches within those object keys. ## Expected Behavior Importing a workspace dependency via subpath export should be included in the dependency graph. I also addressed a related issue where the following resulted in keys of `@my-org/services/default` and `@my-org/services/types`, which is incorrect according to the subpath/conditional export rules. ```json "exports": { "default": "./dist/index.js", "types": "./dist/index.d.ts" } ``` ## Related Issue(s) <!-- Please link the issue being fixed so it gets closed when this is merged. --> Fixes #29486 --------- Co-authored-by: Leosvel Pérez Espinosa <[email protected]> (cherry picked from commit d08ad75)
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: