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.

[sorccu]

This feature is now available in 4.17.0. Please wait for an official announcement (due very soon) to make sure it has been enabled for all accounts.

@Stono Sorry for missing your response. What you've done is very cool. It is unfortunate that the CLI is currently not able to provide a complete solution for you, but I am glad that you have found a way to make the platform work the way you want it to work. We have no intention to intentionally break the APIs used by the CLI, so your solution should continue to work, but there may eventually come a time when incompatible changes are introduced and/or we start using different APIs. Note that you may wish to "pretend" to be the CLI by sending the x-checkly-cli-version header, which is used by the backend to detect support for some features.

We are currently a bit limited on the backend side (or rather, runner-side, if that term makes sense) due to a certain outdated wrapper module that is hard to work with. It is due for removal in the relatively short term, though, so hopefully we will be able to support even more complex features in the future, including support for private/custom dependencies.

Thanks for the ideas!