[TestRunner] tsconfig, babel, tsx, esm metabug

[pavelfeldman]

Module resolver issue extracted as #7066.

#7013
#7037
#7041
#7042
#7142
#7148
#7294
#7855

[curiousercreative]

Is this a regression that may be temporarily worked around with an older version?

[mxschmitt]

This is a meta issue where we collect feedback to make @playwright/test compatible with custom TypeScript, Babel, and ESM. In what of these are you currently interested and what is your use-case?

[curiousercreative]

@mxschmitt I'm new to Playwright test running and simply trying to get an ESM test to run. I tried some other versions of @playwright/test but none seemed to allow for .js files (or .mjs files) to use ESM syntax (with or without a type: 'module' set in package.json). Using a .ts extension seems to appease it for now though...

I might be doing something wrong, but I actually can't get playwright to "find" .mjs files. Always reports no tests found.

[mxschmitt]

Yes, .mjs is not supported currently. We recommend TypeScript for now until we have added MJS support.

[zuzusik]

Doubling down on #7066

We are considering to move from Mocha to Playwright's own test runner.

With Mocha we were able to use ts-node in combination with tsconfig-paths to get tsconfig.json paths feature to work. We really wouldn't want to go back to ../../../blah style of imports...

[bennypowers]

#7452 is probably a dupe of this issue?

I can't just use .ts files because I need

• import.meta.url
• to import actual javascript modules in my test files

[cameronbraid]

My app uses module imports like

import { AffiliateConfig } from "src/util/affiliate";

but these don't work in playwright out of the box (look below for a soloution)

in Jest config I use

module.exports = {
  moduleNameMapper: {
    '^src/(.*)': '<rootDir>/src/$1',
  }
}

in tsconfig I have

{
  "compilerOptions": {
    "paths": {
      "src/*" : ["src/*"]
    }
}

And in playwright config I managed to get it working with app-module-path :

import { PlaywrightTestConfig } from '@playwright/test';
import appModulePath from "app-module-path"

appModulePath.addPath(__dirname)

const config: PlaywrightTestConfig = {
  use: {
    
  },
  retries: 2
};
export default config;

[cyrilletuzi]

First, thanks for this tool!

I can't use Playwright in an Angular project (with a classic official Angular CLI configuration), because of legacy decorators:

SyntaxError: /path/to/src/app/some.service.ts: Support for the experimental syntax 'decorators-legacy' isn't currently enabled (4:1):

(so with @Injectable() in some.service.ts)

at parser (/path/to/node_modules/@babel/core/lib/parser/index.js:52:34)
at parser.next () {
loc: Position { line: 4, column: 0 },
pos: 112,
missingPlugin: [ 'decorators-legacy', 'decorators' ],
code: 'BABEL_PARSE_ERROR'

And as I didn't find a way to override the babel config, I'm stuck.

More generally, it feels weird to be dependent on (complex) babel config files in a primary-TypeScript tool. It should at least do what's needed to respect the tsconfig.json, where experimentalDecorators is enabled.

[andreifloricel]

Hi,
regarding #7066: is it planned to implement this (support of TS path aliases)?
I'm asking because this is a deal-breaker for us and before starting a big migration I need to decide between the playwright-test or playwright-jest runners.

[abierbaum]

#7911 is the key pain point for me right now. I expect that I will need more support for customizing tsconfig.json, but the lack of module path mapping is a deal breaker in my codebase and prevents me from using playwright test within my standard typescript project.

Has anyone found a way to workaround this and allow path aliases even if it is a complete hack? This is preventing me from using playwright with any references to our existing codebase which makes extensive use of path aliases to keep imports stable.

[bhanna1693]

First, thanks for this tool!

I can't use Playwright in an Angular project (with a classic official Angular CLI configuration), because of legacy decorators:

SyntaxError: /path/to/src/app/some.service.ts: Support for the experimental syntax 'decorators-legacy' isn't currently enabled (4:1):

(so with @Injectable() in some.service.ts)

at parser (/path/to/node_modules/@babel/core/lib/parser/index.js:52:34)
at parser.next () {
loc: Position { line: 4, column: 0 },
pos: 112,
missingPlugin: [ 'decorators-legacy', 'decorators' ],
code: 'BABEL_PARSE_ERROR'

And as I didn't find a way to override the babel config, I'm stuck.

More generally, it feels weird to be dependent on (complex) babel config files in a primary-TypeScript tool. It should at least do what's needed to respect the tsconfig.json, where experimentalDecorators is enabled.

I have also been getting this issue! We use openapi generation for our interfaces and http services. The problem for us was we were trying to use interfaces in the openapi folder (which we configured to use TS path in the tsconfig file). For some reason, playwright was trying to read ALL the files (including the services) and hence why we were getting the error. Fixed this by adjusting imports to use exact relative paths (not the ideal solution but it works).

[cyrilletuzi]

@bhanna1693 Thank you for your feedback. Unfortunately, except if if I'm missing something, your solution is okay if you just want to do e2e tests, but if you also want to use Playwright to do unit tests, then the service (and thus the decorator) has to be read.

[bhanna1693]

@cyrilletuzi oh yeah you would be correct

[andreifloricel]

Hi @pavelfeldman @mxschmitt,
sorry to be nagging, but support for module path mapping (#7911) was asked multiple times by several people.
As I said, this is a deal-breaker when choosing between playwright-test or playwright-jest and it would be really helpful if we would know if this feature is planned (or not) in the near future.
Thanks

[zhex900]

Please add module path mapping.

For now, is there a workaround?

#tsconfig.json 
    "paths": {
      "@app/common/*": [
        "../common/src/*"
      ],
      "@app/aws-iot/*": [
        "../aws-iot/src/*"
      ]
    },

[rhyek]

I have a monorepo with several TypeScript apps and I have avoided the use of Babel throughout. For testing I use ts-jest which uses my existing typescript compiler and tsconfig.json under the hood. These are configurable as well. This has worked great for me so far since for path aliases I have been using ts-patch and the typescript-transform-paths plugin for normal app building, so ts-jest will use that same patched compiler. I can maintain parity between runtime and testing TypeScript functionality quite easily.

I think playwright's test runner should do the same thing.

[thernstig]

I noticed that .mjs is supported now, which is nice. But many projects, including mine, using "type": "module". But according to #7452 (comment) this does not even seem planned to support.

We want to use "type": "module" for all our uses, and not require .mjs on any test files.

[actuallyrob]

I have created a Playwright configuration for my monorepo. For now I am only interested in running e2e tests with Playwright.
I have created two projects in my configuration for each app in my monorepo. Each project has its own testDir and testMatch (**/*.e2e.spec.ts) defined. When I run npx playwright test list, Playwright reports that no tests are found. I do however expect my tests that are defined in my test folder to be listed.

When I run npx playwright test, Playwright tries to parse .ts files that do not match my testMatch (and fails because of Aurelia decorators). Why does Playwright do this, and why is my testMatch not working?

[aslushnikov]

When I run npx playwright test, Playwright tries to parse .ts files that do not match my testMatch (and fails because of Aurelia decorators). Why does Playwright do this, and why is my testMatch not working?

Could you please file this separately?

[andrewdavey]

My work-around to avoid all the "../../../foo" noise is to first set the NODE_PATH environment variable to be the test code directory. Then any imports like "foo" resolve correctly.

[Lonli-Lokli]

As an addition for paths support, decorators from tsconfig are also great feature which needs to be supported!

[DOrlov77]

Hello, any plans to fix this issue - the paths support?

[thernstig]

I noticed that .mjs is supported now, which is nice. But many projects, including mine, using "type": "module". But according to #7452 (comment) this does not even seem planned to support.

We want to use "type": "module" for all our uses, and not require .mjs on any test files.

Should I file a separate issue for this? It's hard to track this meta-issue on what is planned and what is not.

[artemrudenko]

Hi, is there any plans to fix this? We are actively using decorators, paths and etc. Sure we can change paths, but what can we do with decorators? I believe that playwright should support all the range of options from tsconfig natively.

[Gojosrepo]

Just to add, it seems support for module path mapping (#7911) also fails for jsconfig as well. (basically the same but throwing it out there).

[awarecan]

tsconfig-paths works to me for #7911

My tsconfig.json

{
  "compilerOptions": {
    "module": "commonjs",
    "target": "es6",
    "outDir": "build",
    "baseUrl": ".",
    "paths": {
      "@my/common-libs": [
        "./modules/common-libs/src"
      ]
    }
  }
}

Add a tsconfig-paths-bootstrap.js to my project root folder

const tsConfig = require("./tsconfig.json");
const tsConfigPaths = require("tsconfig-paths");

const baseUrl = "./build/"; // Either absolute or relative path. If relative it's resolved to current working directory.
tsConfigPaths.register({
    baseUrl,
    paths: tsConfig.compilerOptions.paths
});

Then call playwright likes

node -r ./tsconfig-paths-bootstrap.js ./node_modules/.bin/playwright test ...

[DOrlov77]

@awarecan Nice hack! But when tests are runing by CI systems you are not always may/want to deal with such things.

[irharrier2]

I hope that I haven't miss out anything before writing this comment but is there any update on this issue? We are considering using Playwright test runner but this is a deal-breaker for us.

[cameronbraid]

Another alias solution for yarn users https://yarnpkg.com/features/protocols#why-is-the-link-protocol-recommended-over-aliases-for-path-mapping

{
  "dependencies": {
    "src": "link:./src"
  }
}

[corysimmons]

@cameronbraid Pretty slick but in my specific case we're using @/src/ as the alias.

[stabback]

I came across #7042, which has been folded into this issue.

My use case - I have a monorepo with multiple packages. In one test, I'm attempting to import some data from one package to help build the test. That package happens to import from a third package. That third package also exports .tsx files. Playwright breaks, because it cannot handle .tsx files.

[OriAmir]

I have react app + e2e folder for the playwright testing.
I read all that thread and I still do not understand how I could make playwright recognize absolute paths?
I understand it does not support the tsconfig file for now, but there is any workaround to make it work?

[pavelfeldman]

I'd like to give an update on this issue since there has been some development, which is available in our nightly. It is also about to hit 1.18 RC later this week. I intend to close this metabug and open us to new bugs that would be targeting missing specifics. Please don't hesitate to file those.

1. Playwright Test will now respect tsconfig.json's baseUrl and paths, so you can use aliases
2. There is a new environment variable PW_EXPERIMENTAL_TS_ESM that allows importing ESM modules in your TS code, without the need for the compile step. Don't forget the .js suffix when you are importing your esm modules. Run your tests as follows:

npm i --save-dev @playwright/[email protected]
PW_EXPERIMENTAL_TS_ESM=1 npx playwright test

Let us know whether it worked for you in a new bug with your expectations and repro steps, link this issue for context please!

[chaitraAshu]

@bhanna1693

Hello,
I'm facing the same issue as raised by you while using services in playwright. Can you please explain how did you resolve it. thanks in advance.
below is the error:
Support for the experimental syntax 'decorators-legacy' isn't currently enabled

[mxschmitt]

Please file new feature requests for it or create separate bug reports if you encounter issues.