Open aidant opened 5 months ago
We have reverted the patch to Nx and instead using aliases to link the files up to their correct locations. This behaves better with the jest executor which prefers to have the .ts
extensions in the path aliases, and behaves well in other packages outside the monorepo which have their module resolution set to node.
An example of the new solution we are using looks like the following:
// packages/js/plugins/jest/local-registry.js
moudle.exports = exports = require('./src/plugins/jest/local-registry.js')
// packages/js/plugins/jest/local-registry.d.ts
export * from './src/plugins/jest/local-registry'
With that said, it would still be good to resolve this issue without a workaround as I am treating the packages outside the monorepo as out of scope since the solution to that is to change their module resolution to either node16/nodenext or bundler.
Current Behavior
Importing a nested subpath export from a project in the same Nx workspace fails with a
cannot find module or its corresponding type declarations
typescript compilation error. This error is only present in the@nx/js:tsc
executor and is not present in the typescript language server or when running typescript compiler directly (tsc --noEmit --project ...
).Expected Behavior
The Nx TypeScript executor should produce valid paths when magically swapping in the output directory.
GitHub Repo
No response
Steps to Reproduce
We have a package with a nested subpath export for example
@nx/js/plugins/jest/local-registry
. Except rather than a file at that path we are following the guide from your typescript executor to define additional entrypoints, our subpath export lives in the source directory for examplepackages/js/src/plugins/jest/local-registry.ts
and we are relying on the generate exports field to correctly generate a./plugins/jest/local-registry
subpath export. This all works perfectly, where it falls apart is in the definition of the paths aliases for TypeScript, we have defined the following paths for the package:When running the TypeScript executor with the
NX_VERBOSE_LOGGING_PATH_MAPPINGS
environment variable we see the following output for the respective packages:In our case
dist/packages/js/plugins/jest/local-registry
is not a valid path anddist/packages/js/src/plugins/jest/local-registry.ts
has a bogus file extension.Nx Report
Failure Logs
No response
Package Manager Version
No response
Operating System
Additional Information
We are currently working around the issue by dropping the
.ts
file extension from our TypeScript path mappings for those nested subpath exports and applying the following patch: