[💡 Feature]: Replace ts-node with tsx

[christian-bromann]

Is your feature request related to a problem?

We have been running into issues using ts-node lately, see:

• [🐛 Bug]: Import giving error ERROR @wdio/runner: Error: Cannot find package with paths defined in tsconfig.json #10857
• [🐛 Bug]: source map tests are failing on Windows #11875

For running TypeScript files on demand we currently use ts-node which seems to have difficulties with ESM/CJS as well as sourcemaps.

Describe the solution you'd like.

Switch to tsx which seems to have general better support for it.

Describe alternatives you've considered.

n/a

Additional context

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[wdio-bot]

Thanks for reporting!

We greatly appreciate any contributions that help resolve the bug. While we understand that active contributors have their own priorities, we kindly request your assistance if you rely on this bug being fixed. We encourage you to take a look at our contribution guidelines or join our friendly Discord development server, where you can ask any questions you may have. Thank you for your support, and cheers!

[Delagen]

Now I solved this with running
TSX_TSCONFIG_PATH="./tsconfig.json" NODE_OPTIONS="$NODE_OPTIONS --import tsx" wdio run ./wdio.conf.js

Config need to be compiled to JS or need to be written in plain JS in case to prevent loading ts-node in @wdio/config by detection of extention of config file

[christian-bromann]

@Delagen writing the config to the file system as JS file is not an option. We should provide the ability to just load TS files and execute them.

[Delagen]

@christian-bromann I understand, I use config in JS only to prevent loading of ts-node. All tests and etc. written in Typescript, an d not transpiled to JS manually, all compilation in memory via TSX

Only problem now, is ts-node if it present in node_modules it still try to load by runner, so I have to remove it manually with editing package.lock.json to enable execution in CI.

[goosewobbler]

I took a look at this but it seems there is a fair bit of overlap with the removal of transpiler choice / autoCompileOpts as mentioned in #10362, so maybe we do them together or at least the latter one first.

Some things I noted:

• tsx has no configuration outside of setting a custom tsconfig.json path
• We may need to do some switching on node version to ensure the correct loader syntax is used: https://tsx.is/node#es-modules-only
• The programmatic use of tsx, e.g. replacement for the ts-node register function, may look quite different: https://github.com/privatenumber/tsx/discussions/102

[christian-bromann]

so maybe we do them together or at least the latter one first.

Sounds good to me. I am open to remove autoCompileOpts all together and have it "just" work™.

[erwinheitzman]

@goosewobbler sounds good. I think it is good to stick as much as possible to how the tools work out of the box (no config using wdio but instead document how wdio can be used with tsx). So if tsx recommends using environment variables to appoint a tsconfig then we just point to the tsx documentation, simple, clean and most of all less maintenance and confusion

[goosewobbler]

@erwinheitzman tsx just provides both methods, CLI switch and env var, there's no explicit recommendation. I implemented a tsxTsConfigPath setting which is passed to the switch but can easily remove it if we want to reduce the maintenance load here.

[christian-bromann]

I think being able to provide the path to a tsconfig.json makes sense since many projects have a different tsconfig.json for development and testing. One suggestion: I would call this option in WebdriverIO just tsConfigPath.

[christian-bromann]

Re-assigning this to @goosewobbler as he took a first stab at a PR on this.