bug: namespace module imports break jest testing about js-compute-runtime

[guybedford]

Jest support for JS modules is notoriously unmaintained, and it's widely advised not to use it for modular JS applications. It does not properly support Node.js modules either.

You can just use import 'secret-store' instead of fastly:secret-store here. Alternatively all Fastly APIs are also available as globals - globalThis.SecretStore etc. These workarounds should be perfectly fine for a legacy test runner like Jest.

[jmccann]

@guybedford Is there a recommended runner/config/setup to use that you can point us to that works with a JS compute repo? The https://github.com/fastly/compute-starter-kit-javascript-empty repo has no unit tests in it to follow any supported foundation/patterns around this.

Also, I would think that while you seem to not prefer Jest that it'd still be acknowledged as pretty heavily used in the JS ecosystem and that being able to support it would be of value.

[jmccann]

I don't know if I'm doing something wrong, but those did not seem to work for me testing with the sample repo @rdmulford provided

» git diff | more
diff --git a/src/index.ts b/src/index.ts
index 7af5264..e5e579a 100644
--- a/src/index.ts
+++ b/src/index.ts
@@ -1,7 +1,7 @@
 /// <reference types="@fastly/js-compute" />
 import { Router } from '@fastly/expressly';
 import { RequestHandlerCallback } from '@fastly/expressly/dist/lib/routing/request-handler';
-import { SecretStore } from 'fastly:secret-store';
+import { SecretStore } from 'secret-store';
 
 const router = new Router();
 
» yarn test      
yarn run v1.22.19
$ NODE_OPTIONS=--experimental-vm-modules jest
 FAIL  src/__tests__/index.test.ts
  ● Test suite failed to run

    src/index.ts:4:29 - error TS2307: Cannot find module 'secret-store' or its corresponding type declarations.

    4 import { SecretStore } from 'secret-store';
                                  ~~~~~~~~~~~~~~

Test Suites: 1 failed, 1 total
Tests:       0 total
Snapshots:   0 total
Time:        0.529 s
Ran all test suites.

» git diff | more
diff --git a/src/index.ts b/src/index.ts
index 7af5264..ec30763 100644
--- a/src/index.ts
+++ b/src/index.ts
@@ -1,7 +1,6 @@
 /// <reference types="@fastly/js-compute" />
 import { Router } from '@fastly/expressly';
 import { RequestHandlerCallback } from '@fastly/expressly/dist/lib/routing/request-handler';
-import { SecretStore } from 'fastly:secret-store';
 
 const router = new Router();
 
@@ -22,7 +21,7 @@ router.get('/', async (req, res) => {
 router.listen();
 
 export const getSecret = () => {
-    const secrets = new SecretStore('test-store');
+    const secrets = new globalThis.SecretStore('test-store');
     // not actually getting secrets for demo purpose
     return 'test-secret'
 }

» yarn test      
yarn run v1.22.19
$ NODE_OPTIONS=--experimental-vm-modules jest
 FAIL  src/__tests__/index.test.ts
  ● Test suite failed to run

    src/index.ts:24:36 - error TS7017: Element implicitly has an 'any' type because type 'typeof globalThis' has no index signature.

    24     const secrets = new globalThis.SecretStore('test-store');
                                          ~~~~~~~~~~~

Test Suites: 1 failed, 1 total
Tests:       0 total
Snapshots:   0 total
Time:        0.529 s
Ran all test suites.

I guess my concerns are:

• documentation and examples don't seem to mention or use these methods to import/use the modules
  • it sounds like this is a workaround
• doesn't seem their are any docs/examples on how to properly setup unit testing using edge compute

This isn't the first issue in regards to unit testing issues. #517 and #428 both ran into similar issues. One found a workaround for vitest and another sort of for Jest (didn't fully work for us and we have concerns around keeping it "up-to-date" with this repo ... e.g. it doesn't seem to work with secret store and is dep on version 1.x of this repo currently).

So we are looking for some kind of more official guidance around how to properly unit test code written for edge compute.

[JakeChampion]

It seems others in the community are building custom solutions to try and solve this, for example: ysugimoto/jest-preset-fastly-js-compute. The problem with a solution like that is if it gets out of date things will start to break.

The Jest preset mentioned (ysugimoto/jest-preset-fastly-js-compute) is the exact way I recommend integrating your Fastly JS applications with the Jest test framework.

If you haven't tried using the preset, I recommend that you try that.
If you have tried the preset and it is not working, please open an issue on the repository and please do tag me in the issue.

@ysugimoto-san is the lead maintainer on the project, and is someone who I speak to often, they are also linked with Fastly via their other Fastly related projects such as Falco and are also involved in the Fastly Fast Forward program. All this is to say, that Jest preset is well maintained and we/I aim to keep it well maintained 👍

[JakeChampion]

@guybedford Is there a recommended runner/config/setup to use that you can point us to that works with a JS compute repo? The https://github.com/fastly/compute-starter-kit-javascript-empty repo has no unit tests in it to follow any supported foundation/patterns around this.

Perhaps the test setup for polyfill.io could be a useful reference, it's a complete conpute@edge application using the JS SDK -- https://github.com/Financial-Times/polyfill-service/blob/302ed6092626615ab7c188c572dfb40ae8b807ff/package.json#L30

[jmccann]

I'm not seeing any unit tests in that repo ... seems it is only running integration tests? Let me know if I missed something.

[guybedford]

@jmccann I said that not to state that Jest isn't a good tool, but rather just that it is known to have issues with modern module support across runtimes, beyond this specific case. Did you try the workarounds I mentioned - omitting the namespaces or using the globals? Does that approach work for you here?

[guybedford]

Are you using ts-jest to support TypeScript here? You should be able to disable typing errors from failing tests via https://huafu.github.io/ts-jest/user/config/diagnostics. Then rather have TypeScript checks done via a linting process which fails separate linting checks.

We could consider adding support for these alternative forms to the defined typings, it might offer some flexibility in these kinds of cases.

[guybedford]

Another approach would be to precompile the TypeScript into JavaScript, which is often recommended as well. The tool for this is just tsc of course.

[jmccann]

Looks like ysugimoto/jest-preset-fastly-js-compute#9 should fix our issue. Thanks @JakeChampion !