Renames the NPM workspaces tutorial to TypeScript Packages tutorial and
updates the intro text a bit. The content is all still valid for ts
project references
<!-- 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
The root workspace package is not generated correctly when using Yarn v4
## Expected Behavior
yarn.lock should be created correctly
## Related Issue(s)
Fixes#29451
This PR is a prerequisite to removing `nx` property from `package.json`
files in the new TS setup. It fixes two issues:
1. We always write `nx` property in `package.json` even if it is empty.
This should be done for root projects.
2. Adding an entry to `pnpm-workspace.yaml` is not picked up because
`readProjectConfiguration` only reads the file from disk, not from
virtual `Tree`
This is the next PR to remove the property:
https://github.com/nrwl/nx/pull/29705
…ng default<!-- 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
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- 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
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
<img width="1025" alt="Screenshot 2024-12-21 at 9 51 18 PM"
src="https://github.com/user-attachments/assets/32815566-c532-4186-bc94-4b017b0a84c2"
/>
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
This pull request includes changes to migrate ESLint configuration files
from CommonJS (`.cjs`) to ECMAScript modules (`.mjs`) as the default.
### ESLint Configuration Generation Changes
The changes also ensure consistent generated eslint configs based on the
base eslint config.
- If the workspace root has an `eslint.config.cjs` or `eslint.config.js`
with `module.exports`. When you create a library or application it will
generate an accompanying config at path
`{projectRoot}/eslint.config.cjs` of the same format.
- If the workspace root has an `eslint.config.mjs` or
`eslint.config.mjs` with `export default`. When you create a library or
application it will generate an accompanying config at path
`{projectRoot}/eslint.config.mjs`.
- If no eslint config is found at the workspace root one will be created
`eslint.config.mjs`
## Current Behavior
We currently have no support for React 19, generating only React 18
applications.
## Expected Behavior
Add utils to determine what version of React is installed in the
workspace.
If React 18 is the main version of react installed, continue to generate
React 18 projects.
If React 19 is the main version of react installed, generate React 19
projects.
If no React version is installed or can be determined, generate React 19
projects.
## Current Behavior
When running the `configuration` generator from `@nx/playwright` and
`@nx/cypress` for existing appliactions - they currently generate a
config that is likely to be invalid becaue there is not enough
information to correctly assume the port, target and baseUrl for the
application.
This data is provided by the application generators that call the
`configuration` generator - but that means that users running it
manually must remember to pass the information via flags.
## Expected Behavior
If the serve data is missing, prompt the user to input the correct
information to ensure the config generation is as accurate as possible.
<!-- 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
<!-- This is the behavior we have today -->
The initial version of the docs only allow the use of assignment rules
with Nx Agents.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The updated docs include an overview and example of how to configure
assignment rules to work with self provisioned agents (and DTE in
'manual' mode).
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: Isaac Mann <isaacplmann@users.noreply.github.com>
This PR updates the `@nx/detox:app` generator to match the new TS
solution setup. The `@nx/cypress:configuration` and
`@nx/cypress:configuration` generators are also updated so that they can
be run on existing projects and generator the correct tsconfig files.
The Playwright/Cypress example can be seen as follows:
```shell
# Skip e2e
nx g @nx/react:app apps/demo --bundler vite --e2eTestRunner none
# now configure e2e
nx g @nx/playwright --project demo
```
Now if you add this line to `apps/demo/e2e/example.spec.ts`:
```
const x: number = 'a';
```
And run `nx typecheck demo`, it will pass. This happens because the
`e2e/**/*.ts` pattern is missing. Thus, we need to ensure that a
`tsconfig.e2e.json` project is added for the Playwright spec files. Same
thing with Cypress.
The Detox generator does not support adding configuration to existing
project, so we don't quite get the same problem. The fix for Detox is
just to make sure the tsconfig content is not following the old
(integrated) version, but the updated TS solution version.
## Current Behavior
Detox TS setup is incorrect. Running Cypress and Playwright
configuration generator on existing projects generate invalid setup,
such that spec files are not typechecked.
## Expected Behavior
E2E generators should all generate correct TS setup.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
Generating a js library with esbuild or rollup as bundlers and vitest as
the unit test runner, results in an eslint configuration where the
bundler config file is not ignored from the `@nx/dependency-checks`
rule.
## Expected Behavior
Generating a js library with esbuild or rollup as bundlers and vitest as
the unit test runner, should result in an eslint configuration where the
bundler config file is ignored from the `@nx/dependency-checks` rule.
## Related Issue(s)
Fixes #
## Current Behavior
When generating a non-buildable js library in a workspace using the
integrated setup, a `package.json` file is generated.
## Expected Behavior
When generating a non-buildable js library in a workspace using the
integrated setup, a `package.json` file should not be generated.
## Related Issue(s)
Fixes #
…ts option
<!-- 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
The version generator option `updateDependents` is misspelled as
`updatedDependents` in one of the Nx release docs pages.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
n/a
Fixes #
## Current Behavior
<!-- This is the behavior we have today -->
Creating a new workspace using the TS solution setup always generates a
`tsconfig.base.json` with `module: nodenext` and `moduleResolution:
nodenext`.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Creating a new workspace using the TS solution setup should generate a
`tsconfig.base.json` with `module: nodenext`/`moduleResolution:
nodenext` for Node stacks and `module: esnext`/`moduleResolution:
bundler` for Web stacks (React, Vue).
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
This PR updates our app/lib generators such that `package.json` files
generated have fields in idiomatic order.
e.g.
```json
{
"name": "...",
"version": "...",
"private": true,
"type": "module",
"main": "...",
...
"dependencies": { ... }
}
```
The import fields such as name, version, private, and type are at the
top. Dep fields that could be noisy are at the bottom.
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- 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
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
throw an error when `./gradlew wrapper` or `java -version` failed to
run:
<img width="949" alt="Screenshot 2025-01-09 at 5 33 38 PM"
src="https://github.com/user-attachments/assets/f0b99adc-ff80-4962-8dfe-c1ad11944cac"
/>
<img width="933" alt="Screenshot 2025-01-09 at 5 32 20 PM"
src="https://github.com/user-attachments/assets/11d2286a-cc04-48a0-9839-b67cc93d5cfc"
/>
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
We currently have a `serveTargetName` that defaults to `serve` in the
`@nx/vite/plugin`.
This infers a `vite serve` command for the `serve` task to vite
projects.
While not incorrect, it could be abrasive for users coming from the
`vite` ecosystem to Nx.
The command to start the Vite Dev Server is `vite`, so we should infer
this.
`create-vite` also creates a package.json script with `"dev": "vite"`
meaning users are likely running `npm run dev`.
This creates two points of differences for vite ecosystem users.
## Expected Behavior
Deprecate `serveTargetName` in favour of `devTargetName` to more closely
align with lanugage from the Vite ecosystem.
Infer the command `vite` instead of `vite serve` for the `serve` and
`dev` tasks.
<!-- 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
<!-- This is the behavior we have today -->
We currently second guess our inactivity timer by checking if there are
any open connections. However, there's also a strong chance that plugin
workers will remain open as long as the daemon is open. This means the
daemon stays alive forever and the daemon never shuts down even though
it is inactive.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Instead of checking for open connections in general, the daemon server
will only check for open file watchers. Most Daemon client requests will
restart the server when sending messages so we can safely shut the
server down in most cases. The only case where shutting down the daemon
would cause a disruption is if a file watcher is registered. In those
cases, the daemon will not shutdown due to inactivity.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- 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
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
We currently set Subresource Integrity (SRI) on all scripts injected via
`HtmlRspackPlugin`.
This should be configurable.
## Expected Behavior
Expose an option to set SRI - mark false by default to match Rspack's
`HtmlRspackPlugin` behaviour
## Current Behavior
In Nx 20.2.0, the `ng-packagr-lite` executor stopped producing the
ESM2022 outputs and started producing the FESM2022 outputs. This was due
to the Angular Package Format (APF) dropping the ESM2022 outputs, which
was reflected in the upstream `ng-packagr` implementation. Due to this
change, the libraries' build time and memory increased compared to the
previous versions.
## Expected Behavior
The `ng-packagr-lite` executor should only produce ESM2022 outputs and
avoid running an extra step to bundle the outputs to produce the
FESM2022.
Given the `ng-packagr-lite` executor is not meant to produce publishable
artifacts, its output doesn't need to strictly comply with the APF and
can focus more on build performance.
## Related Issue(s)
Fixes#29519
This PR adds `build-deps` and `watch-deps` targets to buildable JS
projects to help with incremental builds.
A use-case for this is if an app (e.g. Vite React app) has buildable
dependencies that need to be rebuilt when they change.
Say, you create a React app and lib as follows:
```
nx g @nx/react:app apps/react-app --bundler vite
nx g @nx/react:lib packages/react-lib --bundler vite
```
And import `react-lib` inside the app.
```jsx
import { ReactLib } from '@acme/react-lib';
//...
return <ReactLib />
```
The user can then run:
```
nx watch-deps react-app
```
And then serve the app in another terminal:
```
nx serve react-app
```
Then whenever code is updated for a buildable dependency, it'll be
rebuilt and then reloaded in the app.
In the new TS solution setup, non-buildable libraries should still`type:
module`. This can lead to problem since ESM is used but the type will
default to CJS.
This PR also updates `nx sync` for TS references such that transitive
deps are not sycned by default, unless
`NX_ENABLE_TS_SYNC_TRANSITIVE_DEPENDENCIES=true` env var is setup.
Previously, the transitive deps are synced unless the env var disables
it. There isn't a good reason to enable it by default, and it is much
cleaner to not sync by default. This means that if we have libs `a`,
`b`, and `c`, where `a -> b` and `b -> c` dependency edges are formed,
then running:
```
nx sync
```
Will update `a/tsconfig.json` to contain refs to `b` but not `c`.
Whereas:
```
NX_ENABLE_TS_SYNC_TRANSITIVE_DEPENDENCIES=true nx sync
```
Will update `a/tsconfig.json` to contain refs to both `b` and `c`.
<!-- 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
`type` is missing
## Expected Behavior
`type: module` is set in `package.json`
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
Sub-errors are hidden when any project graph error is encountered. This
is detrimental, as things like "missing comma in JSON" get hidden and
make people think that Nx is broken, when in fact their config files are
invalid.
## Expected Behavior
Sub errors are shown regardless of verbose logging (but including their
stack trace if verbose logging is enabled)
### Without Verbose
### With Verbose
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
When we have an inferred target command that matches the entry point of
the cli tool, there is a chance we do not replace package scripts
correctly
e.g.
```
{
"dev": "vite",
"build": "tsc -b && vite build",
"preview": "vite preview"
}
```
this could result in package scripts being updated to
```
{
"dev": "nx dev",
"build": "tsc -b && nx vite:build",
"preview": "nx dev preview"
}
```
## Expected Behavior
We should update the package scripts correctly to match the desired
inferred target
```
{
"preview": "nx preview"
}
```
<!--
_[Please make sure you have read the submission guidelines before
posting an
PR](https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#submit-pr)_
# Community Plugin Submission
Thanks for submitting your Nx Plugin to our community plugins list. Make
sure to follow these steps to ensure that your PR is approved in a
timely manner.
## Plugin Requirements
Before you submit your plugin to be listed in our registry, it needs to
meet the following requirements:
- Run some kind of automated e2e tests in your repository
- Include `@nx/devkit` as a `dependency` in the plugin's `package.json`
- List a `repository.url` in the plugin's `package.json`
i.e.
```
{
"repository": {
"type": "git",
"url": "https://github.com/nrwl/nx.git",
"directory": "packages/web"
}
}
```
Note: We reserve the right to remove unmaintained plugins from the
registry. If the plugins become maintained again, they can be
resubmitted to the registry.
## Steps to Submit Your Plugin
- Use the following commit message template: `chore(core): nx plugin
submission [PLUGIN_NAME]`
- Update the `community/approved-plugins.json` file with a new entry for
your plugin that includes `name`, `url`, `description`:
Example:
```json
// community/approved-plugins.json
[{
"name": "@community/plugin",
"url": "https://github.com/community/plugin",
"description": "This plugin provides the following capabilities."
}]
```
Once merged, your plugin will be available when running the `nx list`
command, and will also be available in the Plugin Registry on
[nx.dev](https://nx.dev/plugin-registry)
-->
# Community Plugin Submission
## @klerick/nx-angular-mf
Custom builder for Angular projects designed to simplify the development
and production of microfrontend applications using native esm module.
The builder integrates with NX to provide seamless support for
development, testing, and deployment of Angular microfrontends.
## Features
- **Microfrontend Support**: Built-in support of native esm module with
dynamic imports them.
- **Server-Side Rendering (SSR)**: Improved SSR compatibility, including
custom module loaders and import maps.
- **Customizable Build Process**: Flexible options for managing
dependencies and extending build configurations.
- **Dev Server Enhancements**:
- Incremental hydration support.
- Dynamic `importmap` generation.
- Automatic dependency resolution and rebuilds.
- **Seamless NX Integration**: Fully compatible with NX workspace for
streamlined project management.
Improves our error handling for swc when using `@nx/js:swc` executor
<!-- 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
<!-- This is the behavior we have today -->
The executor fails to build if the workspace has a newer versions of
`@swc/cli` e.g.(`0.6.0`) is installed since it now uses stderr instead
of message to log errors.
RE: https://github.com/swc-project/pkgs/pull/53
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The executor should pass in this scenario.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#29599
<!-- 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
<!-- This is the behavior we have today -->
Generating a js library with any bundler other than `vite` and with the
`vitest` test runner results in an explicit `test` task in the project
configuration.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Generating a js library with any bundler other than `vite` and with the
`vitest` test runner should not generate an explicit `test` task in the
project configuration. The `test` task should be inferred.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
Introduced custom event tracking for ebook downloads and sales contact buttons using `sendCustomEvent`. Enhanced call-to-action designs by replacing links with `ButtonLink` components and adjusted styling and text for clarity. Updated webinar links and refined headings for consistency.
Re-enabled the `WebinarNotifier` component in the app layout and updated the webinar date and localStorage key to reflect the new event on January 22, 2025.
- Update React Native, React, Remix and Vue library generators to
produce `exports` in the `package.json` for the TS solution setup
- Fix an issue in `@nx/rollup/with-nx` where an unhandled `undefined`
plugin was causing an error to be thrown
- Fix output path of the build task for React Native libraries in the TS
solution setup
<!-- 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
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
This PR adds the new TS setup support to `@nx/web:app` generator.
Previously it errored out since it was not handled.
## Current Behavior
Cannot generate webapp in new setup/
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Can generate webapp in new setup
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
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 <leosvel.perez.espinosa@gmail.com>
