So my question is about the ability to import k6 modules when running a script locally with just node (or ts-node).
I have a typescript performance testing project where I have loads of files, classes, utility methods, etc. All kinds of things to model data objects and so on. So I have a lot of code that is just TypeScript, it doesn’t relate to k6 directly.
So naturally from time to time I want to test the code I’ve written, and running k6 to test that code is of course far from ideal (compared to just being able to run a single ts file with my IDE debugger).
My problem is, that if I test anything in some file, that happens to have any k6 import through some import chain, I get error “cannot find module k6/…”. So I have to refactor out anything I want to test into a separate file, which is a huge waste of time and stupid extra effort.
Is there something that could be done to fix this?
Would the only way be to make some mocks of the k6 modules?
Thanks for reaching out, and welcome to the support forum
I’m really sorry, but I don’t think I didn’t understand what your use case, test setup, and what you’re trying to achieve are from your description. Could you help me clarify some of it?
“import k6 modules when running a script locally with just node”: do you mean by that, that you would like to import k6 modules from within a node project unrelated to k6 and not meant to execute within k6?
"have a typescript performance testing project where I have loads of files, classes, utility methods, etc. ": could you elaborate on that?
“I want to test the code I’ve written, and running k6 to test that code is, of course, far from ideal” it sounds like you would like to be able to use k6 as a node/typescript framework, or did I get that wrong?
From the context I understood, and with the fair share of assumptions I carry, it sounds like you might be trying to use k6 as a framework from within a Typescript project meant to be executed by nodeJS? As opposed to writing a dedicated set of k6 scripts that interact with some software you’re writing and running the run command, that is?
If that’s the case, I’m afraid it is not possible to do what you’re trying to achieve for a couple of reasons:
k6 is, first and foremost, a program, unlike a library. It is written in Go and embeds its own JavaScript runtime (Goja). It means that while k6 can interpret JavaScript code, most of k6’s code itself is not written in JavaScript and does not interpolate with NodeJS. It is, for instance, possible to have k6 transpile JavaScript code that was meant for Node under certain conditions, but the opposite is not true: node cannot execute the code of a k6 module.
k6 does not support Typescript natively yet.
From what I understand, I don’t necessarily see a way forward, yet, but I’ll wait on you to provide more info and will let you know
I write my k6 tests with TypeScript and then webpack them to JavaScript before executing them with k6. And I obviously don’t have everything in one file. I have my API types as TypeScript classes/interfaces, I have many helper functions to create data etc etc.
Everything works fine, would just be nice to be able to test and debug scripts.
Like lets say I have a utility file like this, it exports one function to get a k6 specific thing, but the other function has nothing to do with k6, it’s just TypeScript for doing something. I’d like to quickly step into that function in my IDE debugger and see if I just coded the function correctly. But of course, I can’t launch NodeJS because that same file happens to have a k6 import.
// cool-utility.ts
import { execution } from 'k6/execution';
export const getCurrentVUId = (): number => execution.vu.idInTest;
export const createComplexDataType = (): ComplexDataType => {
// something something, not related to k6
// ...
// lots of code..
// ...
return {
id: "some-id",
name: "some-name",
properties: {},
whatever: "whatever"
}
};
But since you say k6 modules can’t be used via NodeJS, I guess that answers that. I guess only way would be to create NodeJS compatible mocks of the k6 modules.
Node won’t be able to execute the content of the k6/execution module indeed. This is a core module that is indeed written in Go.
This is, as you found out, also the reason why it will make the debugger derail, as it won’t be able to interpret the k6/execution.
Improving the debugging experience is something we have in mind, but with no clear path ahead. Thus, we don’t expect to be able to deliver it anytime soon, unfortunately.
In general, while k6 is quite flexible because it has its own dedicated runtime, code meant to be run by k6 can only be… run by k6.