[🐛 Bug]: Cannot use import statement outside a module with Node 18.19.0

[nilsbrenker]

Have you read the Contributing Guidelines on issues?

• I have read the Contributing Guidelines on issues.

WebdriverIO Version

latest ("@wdio/cli": "^8.24.13")

Node.js Version

18.19.0

Mode

WDIO Testrunner

Which capabilities are you using?

No response

What happened?

This is a follow-up of issue #10901. I started with WDIO installation following these steps

• Created a git repo, cloned it on my system and did npm init
• Proceeded with npm init wdio and accepted the default behavior in most cases (using typescript)
• Ran npm run wdio and faced error (see log output)

The same is working when running either on node 18.18.2 or 20.10.0. The same error occured before on node 20 but was resolved with PR #11202. However, node 18.19.0 is now also using npm 10.2.3 and the if statement added with PR #11202 only checks on nodeMajorVersion() >= 20 to set additional node options. Thus I assume that the root cause is npm 10.

What is your expected behavior?

Running the generated wdio project on node 18.19.0 shall work without issues as it does on node 18.18.2 and 20.10.0

How to reproduce the bug.

• Clone https://github.com/nilsbrenker/wdio-sample/tree/main
• run npm install
• run npm run wdio with node 18.19.0

Relevant log output

C:\Users\...\git\wdio-sample>npm run wdio

> wdio-sample@1.0.0 wdio
> wdio run ./wdio.conf.ts

2023-12-07T09:37:05.512Z ERROR @wdio/config:ConfigParser: Failed loading configuration file: file:///C:/Users/.../git/wdio-sample/wdio.conf.ts: Cannot use import statement outside a module
C:\Users\...\git\wdio-sample\wdio.conf.ts:1
import type { Options } from '@wdio/types'
^^^^^^

SyntaxError: Cannot use import statement outside a module
    at internalCompileFunction (node:internal/vm:73:18)
    at wrapSafe (node:internal/modules/cjs/loader:1274:20)
    at Module._compile (node:internal/modules/cjs/loader:1320:27)
    at Module._extensions..js (node:internal/modules/cjs/loader:1414:10)
    at Module.load (node:internal/modules/cjs/loader:1197:32)
    at Module._load (node:internal/modules/cjs/loader:1013:12)
    at ModuleWrap.<anonymous> (node:internal/modules/esm/translators:202:29)
    at ModuleJob.run (node:internal/modules/esm/module_job:195:25)
    at async ModuleLoader.import (node:internal/modules/esm/loader:336:24)
    at async ConfigParser.addConfigFile (file:///C:/Users/.../git/wdio-sample/node_modules/@wdio/config/build/node/ConfigParser.js:86:36)
    at async ConfigParser.initialize (file:///C:/Users/.../git/wdio-sample/node_modules/@wdio/config/build/node/ConfigParser.js:48:13)
    at async Launcher.run (file:///C:/Users/.../git/wdio-sample/node_modules/@wdio/cli/build/launcher.js:41:9)

Code of Conduct

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

Is there an existing issue for this?

• I have searched the existing issues

[erwinheitzman]

Simply do not run 'npm init' before running 'npm init wdio .' and it should work just fine

[erwinheitzman]

The issue is that because you initialised the package twice it is missing the type property in the package.json

[nilsbrenker]

Hi @erwinheitzman,
when I add "type": "module" to the package.json, I get the following error:

> wdio-sample@1.0.0 wdio
> wdio run ./wdio.conf.ts

2023-12-07T12:19:24.639Z ERROR @wdio/config:ConfigParser: Failed loading configuration file: file:///C:/Users/.../git/wdio-sample/wdio.conf.ts: exports is not defined in ES module scope
ReferenceError: exports is not defined in ES module scope
    at file:///C:/Users/.../git/wdio-sample/wdio.conf.ts:2:23
    at ModuleJob.run (node:internal/modules/esm/module_job:194:25)

Adding "type": "commonjs" leads to the error message as in the log output in my initial description.

As said this is working fine on lower and higher node versions, just on node 18.19.0 it runs into this issue. On node 18.18.2 and 20.10.0 I can use either of the type values in the package.json or just leave the property out as in my repo and wdio works without issue.

[erwinheitzman]

I did not say to manually add it, I said that you should not instantiate the project twice in a row. Simply running 'npm init wdio@latest .' With the node version you shared, works fine

[erwinheitzman]

That said, if the git repo already had typescript installed, I know this is currently an issue as it won't install any TS related packages for example

[nilsbrenker]

First of all thank you very much for the quick help. Indeed it's working correctly if I just run npm init wdio@latest as suggested.

But I'm still confused how to fix an existing ts repo where wdio was installed later on (without type module) and which was running fine on node 18 until the recent update to 18.19.0. Therefore I tried to add the type module to my sample repo, throw away the package-lock and node_modules to do a fresh reinstall but still I then run into this ReferenceError: exports is not defined in ES module scope error. I also diffed the files for any other deviations.
Is there any good reason why wdio is running on older and newer node versions than 18.19.0 in my sample repo? Are this just lucky coincidents that it's running although I did this setup mistake?
Sorry if I miss something obvious 🙈

[erwinheitzman]

It's probably unrelated to node and is likely just a coincidence. Regarding the difference, I assume that typescript was already installed before you ran the npm init wdio . command, in which case it skips installing typescript related packages. You can check the package.json in the working setup and copy them over (don't forget to run npm i after).

I'll keep this issue open and look into this specific issue as someone ran into this not too long ago as well.

[christian-bromann]

My hunch is that it has to do with this change that was introduced in Node.js v18.19:

ESM and customization hook changes
Leverage loaders when resolving subsequent loaders
Loaders now apply to subsequent loaders, for example: --experimental-loader ts-node --experimental-loader loader-written-in-typescript.

Contributed by Maël Nison in nodejs/node#43772.

[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!