webdriverio: [🐛 Bug]: ts page class is imported as .js and failing test when updating the import

Have you read the Contributing Guidelines on issues?

WebdriverIO Version

8.0.13

Node.js Version

18

Mode

WDIO Testrunner

Which capabilities are you using?

{
    browserName: 'chrome'
    browserVersion: 'latest',
    platform: 'macOS'
}

What happened?

i am using typescript with webdriverio and page objects files are also in .ts In actual test import for page are written as .js which should not be the case .

When I remove the file extension (same approach as v7) and run then i get error

What is your expected behavior?

page import statement should not have file extension or based on actual file and test should run successfully.

How to reproduce the bug.

git clone https://github.com/testSadab/WebdriverIOMochaTS.git git checkout import_issue npm install npm run wdio

Relevant log output

git link: https://github.com/testSadab/WebdriverIOMochaTS/tree/import_issue
logs: https://github.com/testSadab/WebdriverIOMochaTS/blob/import_issue/log.txt

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

About this issue

  • Original URL
  • State: closed
  • Created a year ago
  • Comments: 31 (23 by maintainers)

Commits related to this issue

Most upvoted comments

The way you’re resolving your ESM code is not correct. Make the following changes:

  • In tsconfig.json, change module: "ESNext" to target: "ESNext"
  • In package.json, remove type: "module"
  • Wherever you import page.js, change it to just import page, as it’s a .ts file.

This made your code work for me.

@christian-bromann I’ve finally gotten a chance to make progress on this, but I’m having trouble actually getting to test it within the Gitpod I made for myself (my first time using Gitpod)… but just wanted to let all the people watching this that I should have something soon, gonna just have to try setting up this project locally and test it that way… otherwise I’ll schedule an office hours slot for further assistance.

So what I’m actually want to ask is if you can only use v8 in a EMS project?

Yes, you can use WebdriverIO v8 in a CJS context. Note that your code base can be CJS but your WebdriverIO files are in ESM. There are certainly some interoperability issues we are working on fixing.

If that’s another bug to report, etc, then I’m happy to create it and look into it, but just first need to confirm that I have the right understanding.

Yes using the @wdio/cli can only be done in ESM, please raise an issue that asks to make the launcher compatible to CJS context.

@christian-bromann Sorry I got busy with my day job, so haven’t worked on it yet. The only thing that commit I made did was make the auto-generated files when choosing TS work by making it use CJS. So in a way it was better than it not working at all, but I’ll see if I can grab a moment to make the proper fix soon.

@christian-bromann Well in that case, we’d be better off removing the ask for what module system to set and just force it to ESM. If we want to do that, then we’d want to add in something to set that when the entry path is npx wdio ./.

Personally I think CJS is going to stick around for a few more years at least as many libraries have yet to switch over and there’s still a lot of backwards compatibility built in for it, but it probably doesn’t hurt to force folks to start out using ESM if it’s a brand new project we’re making for them. I’ll take out the choice between CJS/ESM in the npm init wdio ./ entrypoint to ensure that. We do have to still check if it’s CJS/ESM in case they made the package.json themself without the property or with module: commonjs so we generate the sample files correctly.