## Current Behavior
The Nx Vite TsConfig paths plugin incorrectly resolves to workspace root
tsconfig files instead of project-specific ones, causing path aliases
like `@/contexts` to fail resolution.
## Expected Behavior
The plugin should check for project-specific tsconfig files
(`tsconfig.app.json`, `tsconfig.lib.json`, `tsconfig.json`) before
falling back to workspace root configurations.
## Related Issue(s)
Fixes#28945🤖 Generated with [Claude Code](https://claude.ai/code)
Co-authored-by: claude[bot] <209825114+claude[bot]@users.noreply.github.com>
Co-authored-by: Coly010 <Coly010@users.noreply.github.com>
## Current Behavior
When TS Path Mappings are combined with an explicit extension of the
build outcome of a file, the `nxViteTsPaths` plugin cannot resolve the
file.
e.g.
```ts
import {something} from '@mylib/file.js';
// tsconfig paths
"@mylib/*": ["mylib/src/*"]
```
In this case, we fallback to the file system to try find the file, and
we do it by adding extensions to the end of the path.
e.g.
```ts
@mylib/file.js.js
@mylib/file.js.ts
@mylib/file.js.mts
etc
```
## Expected Behavior
Perform the usual logic first to try find the file in the file system.
If the file is still not resolved AND the path ends with an `extname`
that we support in `options.extensions`, strip the extension from the
path and try append the different extensions again and resolve against
the filesystem.
This allows for the case where someone has a file in their file system
that _is_ `file.js.js` to be resolve via `@mylib/file.js` as well as
when the explicit path is provided.
## Related Issues
Fixes#29948
## Current Behavior
When Vite build is run where:
- `nxViteTsPaths` plugin is enabled
- `--verbose` or `NX_VERBOSE_LOGGING=true` is set
The resulting logs can be quite noisy.
## Expected Behavior
When `debug` is explicitly set to false, ignore logs even when
`--verbose` is passed.
Usage:
```ts
nxViteTsPaths({ debug: false })
```
## Related Issue(s)
Fixes#29320
---------
Co-authored-by: Leosvel Pérez Espinosa <leosvel.perez.espinosa@gmail.com>
This PR brings back the CRA migration that was missing since Nx 18.
## Current Behavior
<!-- This is the behavior we have today -->
`nx init` does not migrate CRA apps
## Expected Behavior
`nx init` migrates CRA apps to Vite since CRA is deprecated
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
When multiple processes/tasks are running in parallel for a single
project that produce tmp tsconfig files for buildable libraries, they
can clobber each other.
## Expected Behavior
Ensure the config file is generated with a unique id to prevent
clobbering
The fallback path resolution was only happening if the resolvedFile was
a falsy value, so it was returning inexistent filepaths.
This pull request includes a small but important change to the
`packages/vite/plugins/nx-tsconfig-paths.plugin.ts` file. The change
improves the reliability of resolving file paths by checking if the
resolved path exists before proceeding with fallback file matching.
*
[`packages/vite/plugins/nx-tsconfig-paths.plugin.ts`](diffhunk://#diff-ad026b24ed45d9df484cabc7e277fc9b4d7759560af36bf357cbc4186725ae0bL174-R176):
Added a check to verify if the resolved file path exists before using
fallback file matching.
*
<!-- 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 resolver doesn't resolve the full file path, it ignores the file
extension. For example, for a path like this:
`import mergeClassNames from '@projects/global/utils/mergeClassNames'`
It resolves to
`absolutePath.../projects/libs/global/src/utils/mergeClassNames`
When vite is building a project, it doesn't find the file and it errors.
This happens because the resolved file path is not a falsy value, thus,
it doesn't run the fallback file path matching.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
What is expected is that it resolves to (notice the file extension)
`absolutePath.../projects/libs/global/src/utils/mergeClassNames.ts`
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
---------
Co-authored-by: Leosvel Pérez Espinosa <leosvel.perez.espinosa@gmail.com>
<!-- 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 -->
When there is a path mapping like:
```
"match-lib-deep/": ["libs/lib1/src/*"],
"match-lib-top-level": ["libs/lib2/src/*"],
"match-lib/*": ["libs/lib3/src/*"],
```
Imports to `match-lib-deep` or `match-lib-top-level` will try and use
the last `match-lib` path mapping as the trailing `/` is not accounted
for in the `startsWith` check.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The correct path mapping is matched.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
N/A
Use `basename` for retrieving the filename in `findFile` function from
`nx-tsconfig-paths.plugin` that previously led to an unresolved error
for files with dot suffixes e.g.`/dir/file.suffix.ext`
<!-- 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
For files that have the same name but one of them has a suffix, e.g.
```ts
- lib1
- file.ts
- file.i18n.ts
- apps
- app1
- main.ts
- tsconfig.base.json // with { "paths": { "@lib1/*": ["lib1/*"] }}
```
The resolving process is incorrect because the `import value from
'@lib1/file.i18n'` from `apps/app1/main.ts` every time resolves to
`file.ts,` and the `parse` method from the `node:path` splits away the
suffix from the name.
## Expected Behavior
`import value from '@lib1/file.i18n'` should work correctly if you
import them from another package
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#27852
---------
Co-authored-by: Colum Ferry <cferry09@gmail.com>
closed#28615
<!-- 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#28615
This PR updates the tsconfig paths plugin for Vite such that it resolves
paths with file extensions as well.
<!-- 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#22868
<!-- 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 -->
In Yarn and PNPM Workspaces, the `nxViteTsPaths`'s `resolveId` is not
called because Vite has already tried to resolve the module.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Ensure the `nxViteTsPath`'s logic is run before vite's internal
resolver.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#20520
<!-- 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 -->
When nxViteTsPaths resolves the tmp tsconfig we create for the buildable
libs, it uses the absoluteBaseUrl of the tsconfig to when creating the
ESM matcher for resolving files.
There is no baseUrl set, therefore the absoluteBaseUrl becomes the
directory of the tmp tsconfig
This means the paths to the built artifacts are incorrect
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Use the workspace root, which lines up with the output locations for
built artifacts, for the baseUrl for the tmp tsconfig
## 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 -->
`nxViteTsPaths` does not check if the mode is test and only filters the
`run-many` command based on whether Vite's config.command === serve.
Vitest will set `config.command` to serve, even for `test` targets.
It does set `mode = test` however.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
When `mode === test`, we do not invoke `nx run-many`
## 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` -->
## Current Behavior
<!-- This is the behavior we have today -->
We do not support incremental builds with vite when using inference
plugin
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Support incremental builds with vite when using inference plugin
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
Since v18.2.3 (e4c4697f69cf29c50aced1997715a7da5f680e23) the
`tsconfig.generated.json` file generated if `"buildLibsFromSource":
false` is placed under a path containing the current build target. The
`nx-tsconfig-paths` plugin of `@nx/vite` was not updated accordingly, so
now it doesn't find `tsconfig.generated.json`, effectively causing
`@nx/vite` to ignore the `"buildLibsFromSource": false` setting.
## Expected Behavior
With this PR, `nx-tsconfig-paths` finds `tsconfig.generated.json` at the
correct path, so `"buildLibsFromSource": false` works as it did before
v18.2.3.
