Bug: path alias not exported correctly in d.ts files

[nielk]

Given

import { defineConfig, devices, type VideoMode } from '@playwright/test'
import { defineBddConfig } from 'playwright-bdd'

const videoModes: ReadonlySet<string> = new Set([
  'off',
  'on',
  'retain-on-failure',
  'on-first-retry',
])

function isVideoMode(repr: string): repr is VideoMode {
  return videoModes.has(repr)
}

const envVideo: () => VideoMode | undefined = () => {
  const v = process.env.PLAYWRIGHT_VIDEO

  if (!v || !isVideoMode(v)) {
    return undefined
  }

  return v
}

const testDir = defineBddConfig({
  features: 'features/*.feature',
  steps: 'steps/*.ts',
  quotes: 'backtick',
  outputDir: '.features-gen',
})

export default defineConfig({
  testDir,
  reporter: [['html', { outputFolder: 'playwright-report' }]],
  fullyParallel: true,
  snapshotDir: 'snapshots',
  use: {
    screenshot: 'only-on-failure',
    timezoneId: 'Europe/Paris',
    locale: 'fr-FR',
    baseURL: process.env.PLAYWRIGHT_WEBHOST || 'http://localhost:5000',
  },
  expect: {
    toHaveScreenshot: {
      maxDiffPixels: 50, // TODO: 20
      stylePath: 'screenshot.css',
    },
  },
  projects: [
    {
      name: 'chromium',
      use: {
        ...devices['Desktop Chrome'],
        viewport: { width: 1280, height: 720 }, // TODO: { width: 1920, height: 1080 },
        video: envVideo() || 'off',
      },
    },
  ],
})

{
  "compilerOptions": {
    "target": "es2021",
    "module": "commonjs",
    "strict": true,
    "moduleResolution": "node",
    "esModuleInterop": true,
    "noEmit": true,
    "removeComments": true,
    "pretty": true,
    "noUnusedLocals": true,
    "noUnusedParameters": true,
    "noImplicitReturns": true,
    "noFallthroughCasesInSwitch": true,
    "noUncheckedIndexedAccess": true,
    "baseUrl": "./",
    "paths": {
      "_/*": ["../src/*"]
    }
  },
  "include": ["**/*.ts"],
  "exclude": [
    "node_modules",
    "features",
    "playwright-report",
    ".features-gen"
  ]
}

When

When I run npx tsc --noEmit

Then

I get this error:

yarn run v1.22.22
$ cd ./e2e && yarn build && yarn playwright
$ tsc --noEmit && bddgen
node_modules/playwright-bdd/dist/reporter/cucumber/base.d.ts:9:32 - error TS2307: Cannot find module '#cucumber/formatter/EventDataCollector.js' or its corresponding type declarations.

9 import EventDataCollector from '#cucumber/formatter/EventDataCollector.js';
                                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Found 1 error in node_modules/playwright-bdd/dist/reporter/cucumber/base.d.ts:9

error Command failed with exit code 2.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
error Command failed with exit code 2.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

But I expect

I expect that d.ts files do not include path alias # but ../../ instead. Because external project have no clue about the path alias used in playwright-bdd package ?

Isolated demo

https://github.com/nielk/playwright-bdd-example/pull/1

Occurs after running npm run build

Environment

• node v20.16.0
• Mac OS 14.6.1

[vitalets]

Thanks for the report, I confirm the bug. On the user-land there are 2 options:

1. set module field to node16 or nodenext in tsconfig.json (recommended). Then TypeScript will resolve # imports. But I believe there always be projects sticked to commonjs, so I will investigate and maybe revert subpath imports for now or clarify that in docs
2. set "skipLibCheck": true

@nielk could you check, does it work for you?

[nielk]

2. "skipLibCheck": true

It does the job, thank you!

[vitalets]

By the way, if you set module to node16 - does it break something in you project? Per TS docs - there should not be any strong reasons to stick with commonjs. But I'm curious, how it goes in real projects.

[vitalets]

Subpath imports were reverted.

[nielk]

By the way, if you set module to node16 - does it break something in you project? Per TS docs - there should not be any strong reasons to stick with commonjs. But I'm curious, how it goes in real projects.

Sorry for the late response, on my project every time we struggled with esm stuff it was because we use npm package that did not migrated to esm yet.