[BUG] Typescript - Relative path is resolving relative to tsconfig's baseUrl
See original GitHub issueContext:
- Playwright Version: 1.24.0
- Operating System: Debian 11
- Node.js version: 12.17.0
- Typescript version: 4.6.4
file structure
frontend/
tsconfig.json
src/
playwright/
utils.ts
tests/
forms_cms_standard.spec.ts
tsconfig.json
{
"compilerOptions": {
...
"baseUrl": "src"
},
"include": [
"src/**/*",
"playwright/**/*",
...
]
}
forms_cms_standard.spec.ts
is importing from utils.ts
relatively. import { ... } from "../utils
.
frontend ➜ npx playwright test playwright/tests
Running 0 test using 0 worker
Error: Cannot find module '/home/jchi/projects/bifrost/frontend/utils'
Require stack:
- /home/jchi/projects/bifrost/frontend/playwright/tests/forms_cms_standard.spec.ts
- /home/jchi/projects/bifrost/frontend/node_modules/@playwright/test/lib/loader.js
- /home/jchi/projects/bifrost/frontend/node_modules/@playwright/test/lib/runner.js
- /home/jchi/projects/bifrost/frontend/node_modules/@playwright/test/lib/cli.js
- /home/jchi/projects/bifrost/frontend/node_modules/@playwright/test/node_modules/playwright-core/lib/cli/cli.js
- /home/jchi/projects/bifrost/frontend/node_modules/@playwright/test/node_modules/playwright-core/cli.js
- /home/jchi/projects/bifrost/frontend/node_modules/@playwright/test/cli.js
at playwright/tests/forms_cms_standard.spec.ts:5
3 |
4 | import forms from "../../cypress/fixtures/forms_cms.json";
> 5 | import {
| ^
6 | blockTrackingHosts,
7 | fillFormFields,
8 | goToWithParamTraits,
at Object.<anonymous> (/home/jchi/projects/bifrost/frontend/playwright/tests/forms_cms_standard.spec.ts:5:1)
If I remove baseUrl
from tsconfig
playwright runs just fine, although I can’t do that since the non-relative imports in my codebase will break.
This behavior is different from the documented Typescript module resolution, where relative imports should not be affected by baseUrl
.
And this is confirmed when running tsc --traceResolution
, as it does not error, and resolves utils.ts
correctly
...
======== Resolving module '../utils' from '/home/jchi/projects/bifrost/frontend/playwright/tests/forms_cms_standard.spec.ts'. ========
Module resolution kind is not specified, using 'NodeJs'.
Loading module as file / folder, candidate module location '/home/jchi/projects/bifrost/frontend/playwright/utils', target file type 'TypeScript'.
File '/home/jchi/projects/bifrost/frontend/playwright/utils.ts' exist - use it as a name resolution result.
======== Module name '../utils' was successfully resolved to '/home/jchi/projects/bifrost/frontend/playwright/utils.ts'. ========
...
Issue Analytics
- State:
- Created a year ago
- Reactions:1
- Comments:5 (4 by maintainers)
Top Results From Across the Web
Documentation - Module Resolution - TypeScript
A non-relative import can be resolved relative to baseUrl , or through path mapping, which we'll cover below. They can also resolve to...
Read more >Why are these tsconfig paths not working? - Stack Overflow
You can see that a path such as shared/someFolder/someScript will resolve correctly to the shared folder in my project, which is a load...
Read more >Typescript paths with ts-node, ts-node-dev and Jest | Medium
From the TypeScript docs: baseUrl: Specify the base directory to resolve non-relative module names. paths: Specify a set of entries that ...
Read more >tsconfig-paths - npm
The typescript compiler can resolve these paths from tsconfig so it will compile OK. But if you then try to execute the compiled...
Read more >TypeScript baseUrl and relative paths configuration => issue ...
We have configured a baseUrl (https://www.typescriptlang.org/docs/handbook/module-resolution.html#base-url) in our tsconfig.json file so that we ...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Will be fixed in the next release by #16395.
I experience the same issue and seem to have found the cause.
There must be a directory (or file) at the top-level that is confusing the path resolver. I.e. the logic of the resolver seems to be “if I can find it at the top-level, take it, but if not, then fall back to relative import”. The original test did not have the top-level entry. I’ve added a failing test in #16338.