fix: force moduleResolution: 'node' when ts-node is registered in the… #28709
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
… cypress process to make sure value is compatible with commonjs (which is already forced). [run ci]
Additional details
This PR attempts to fix #27731, which was reopened when #26308 did not resolve the issue.
Currently in Cypress, if a user has
typescript
installed and the project is NOT an ES Module (viatype: 'module'
), Cypress sets the module tocommonjs
when registeringts-node
to load the project's config. This was to guarantee that cypress could run the transpiled config in its owned node process as node can natively runcommonjs
with ease. This however started being a problem when newmoduleResolution
properties were introduced to newer versions of typescript that are incompatible withcommonjs
.To avoid this issue, this PR sets the
moduleResolution
tonode
to guaranteecommonjs
as a module configuration will work. #26308 attempted to fix this in a similar way, except themoduleResolution
setting tonode
happened behind toTS_NODE_COMPILER
flag, which is only set when a user provides a custom compiler, which the Cypress monorepo does here, which made the issue appear to be fixed. This isn't usually set in production, hence why #27731 was opened.This should resolve the issues with
next.js
scaffolding, but e need to figure out a more long term solution to processing the users cypress config with typescript. Right now we use the user's typescript configuration to transpile files executed by the cypress node child process, which is a gamble on compatibility (hence the forcing, but isn't really an option withts-node/esm
due to TypeStrong/ts-node#1997 (comment)).To verify the issue, standalone binaries have been build on the commit in this PR 0481c7a. From testing, it looks like the fix works.
Steps to test
Since reproducing this issue is difficult in the cypress monorepo due to the
TS_NODE_COMPILER
flag set, standalone binaries have been build on the commit in this PR 0481c7a. Follow thenext.js
reproduction steps in #27731 to create a newnext.js
project with the CLI, install cypress, and make sure a user can set up their cypress project for the first time without error and run tests.How has the user experience changed?
next.js@14
with cypress e2e tests and typescript installed should run out of the box. This PR does NOT resolve CT support fornext.js@14
, mentioned in #28185.PR Tasks
cypress-documentation
? (N/A)type definitions
? (N/A)