feat: Checkly check-parser use the paths alias defined in tsconfig.json

[obi-awyss]

What problem does this feature solve?

Currently the Checkly's check-parser does not consider https://www.typescriptlang.org/tsconfig#paths when resolving local imported files.

With some paths alias defined in tsconfig.json for the project:

{
  "compilerOptions": {
    "baseUrl": ".",
    "paths": {
      "_/*": ["./src/*"],
      "_checkly/*": ["./checkly/*"]
    },
...

Any spec files that use an alias in the import statement will also work in Checkly like it already does in Playwright.
import { baseURL } from '_checkly/constants';

Today this does not work and you get this error:

Parsing your project... !
    Error: Error loading file /Users/awyss/gitlab.obsec1/frontend/app-product/checkly/__checks__/browser-group.check.ts
    Error: Encountered an error parsing check files for /Users/awyss/gitlab.obsec1/frontend/app-product/src/e2e/login.spec.ts.

    The following NPM dependencies were used, but aren't supported in the runtimes.
    For more information, see https://www.checklyhq.com/docs/runtimes/.
        /Users/awyss/gitlab.obsec1/frontend/app-product/src/e2e/login.spec.ts imports unsupported dependencies:
                _checkly/constants

        at Collector.validate (/Users/awyss/gitlab.obsec1/frontend/app-product/node_modules/checkly/src/services/check-parser/collector.ts:48:13)
        at Parser.parse (/Users/awyss/gitlab.obsec1/frontend/app-product/node_modules/checkly/src/services/check-parser/parser.ts:146:15)
        at Function.bundle (/Users/awyss/gitlab.obsec1/frontend/app-product/node_modules/checkly/src/constructs/browser-check.ts:109:27)
        at new BrowserCheck (/Users/awyss/gitlab.obsec1/frontend/app-product/node_modules/checkly/src/constructs/browser-check.ts:69:35)
        at /Users/awyss/gitlab.obsec1/frontend/app-product/checkly/__checks__/browser-group.check.ts:30:5
        at Array.forEach (<anonymous>)
        at /Users/awyss/gitlab.obsec1/frontend/app-product/checkly/__checks__/browser-group.check.ts:28:13
        at Array.forEach (<anonymous>)
        at Object.<anonymous> (/Users/awyss/gitlab.obsec1/frontend/app-product/checkly/__checks__/browser-group.check.ts:9:18)
        at Module._compile (node:internal/modules/cjs/loader:1155:14)

This is because Checkly check-parser is not resolving the alias to the local file and instead assumes an NPM package.

How would you implement this feature?

Improve the Checkly's check-parser to use the the information in the tsconfig.json file to resolve any import of a local file that use an alias at the beginning of the import path.

import { baseURL } from '_checkly/constants';
import { foo } from '_/someFolder/foo';

becomes

import { baseURL } from './checkly/constants';
import { foo } from './src/someFolder/foo';

https://www.typescriptlang.org/tsconfig#paths

[eoinmurray]

Same issue here, nextjs project with a tsconfig alias setup, means that I can't use checkly, or I need to rewrite all the paths in my project (not possible)

[realmunk]

Same issue here. This is default typescript functionality, and would enable easier user adoption for your product. ➕

[Stono]

+1 to this, please support tsconfig paths.

[sorccu]

I'll be looking into this soon after some higher priority items.

[sorccu]

This is being worked on in #1006. The branch currently already supports collecting the correct set of files, but unfortunately the backend also needs to know the tsconfig path mapping, and that will require backend changes.

[Stono]

I thought you might like to know i've pivoted away from using the checkly-cli entirely and built my own to tackle some problems (such as this) and also code sharing (importing shared functions from external npm libraries/node_modules).

The approach I have taken is to use https://rollupjs.org/, I target my spec file and let rollup tree shake the dependencies required into a vendor.js bundle, which I then upload to the check.

You can see my local code here:

And then what gets uploaded to checkly:

This solves so many problems.

In my personal opinion, this is why you need to ensure the checkly-api is fully featured and you aren't pushing people to use your cli with private / hidden APIs. It enables customers to solve the problems that they face in a timely manner rather than relying on your cli abstraction to fix all their problems. Equally, you might get some interesting ideas/concepts coming out of customers - such as this, that might open up new ways of thinking about the problem space.