K6 typescript monorepo setup with custom libraries and tree-shaking

Grafana k6
,
1

Hey!

I’m trying to achieve something like this:

  • Have a monorepo with various testing projects (e.g. both e2e and k6 tests)
  • Have a common typescript library that will share common query constants between different testing projects.
  • k6 tests are written in typescript, compiled (in any reasonable way) into js output, they import queries from the common lib and work.

So far, I’ve been able to get 2 results:

  1. The library is included as require("lib-name"), but tests are failing with GoError: The moduleSpecifier "lib-name" couldn't be recognised as something k6 supports.
  2. The webpack config is adjusted to embed the contents of the library into each file directly, which makes the test work.
    • But, even if ESM import statements are used - I never managed to get the tree-shaking to work, which means that each test file will include the full library contents, and not just the imported parts.
    • This does not scale well…

The questions I have are:

  1. Is it possible to avoid the moduleSpecifier error while continuing to use the typescript lib without writing it as a go extension?
    • E.g. maybe my min reproduction repo can be adjusted in some way to make it work?
  2. If the only way is to include contents into each test file - is tree-shaking achievable?
    • I tried a couple of different configuration options for webpack/babel/typescript/package.json, but none worked.

Thanks in advance!

2

Hi @axtrusov, welcome to the community forum!

The error you are getting is because webpack instead of bundling the library … doesn’t and let k6 resolve. k6 isn’t node based and is in general not compatible with it … including not supporting it require algorithm. You can read more in the modules docs

The problem comes from the externals configuration in webpack which tries to only match stuff that are k6 or start with k6/ or are urls with https https://, but apperantly also match anything starting with k6. So it also matches the way you;ve named your library.

Swithcing to externals: /^(k6$|https?\:\/\/|k6\/)(\/.*)?/, did the trick … although it probably should be done better to begin with. OR you can just rename the library to not start with k6 :wink: that will probably be easier in this case.

After that I do get more errors but they seem to be around npm/webpack not being able to find the helper module. I couldn’t make it work and the information online seems to be conflicting. This will probably be easier to be answered by people working with webpack nad npm.

There also is an experimental enhanced mode which does type erasure for k6. So you might be able to skip all this and just directly import the code in k6 as long as you import file paths.

I have no experience with webpack tree shaking but it seems it needs quite a lot of speciifc configuration to get it working and it seems it works better if the input and output is ESM not commonjs. But I can’t give you a direct guidance. Likely again better to ask in webpack.

This does not scale well…

I don’t know what your scale is … but you might want to try without it and see if you have problems before optimizing - I have never heard of someone having problems with this in k6.

Hope this helps you!

3

Hey!

Thanks for the quick reply!

The scaling I was talking about is that if the whole lib content is included in every resulting .js k6 test file - the output size will grow drastically over time as both the number of tests grow and the lib contents/dependencies grow.

As for the other parts. The externals change helped to make the test run and start using the libs contents, but if tests\dist\get-200-status-test.js is checked, it will still have the whole lib contents, including parts that are not explicitly used (e.g. both Test 1 and Test 2 console logs), which is the main tree-shaking issue I’m trying to resolve.

I briefly tried the experimental module and it was giving me same moduleSpecifier error. And even without local common lib, it was throwing the same error for other npm-based libs. Maybe there is a way to influence esbuild configuration is some way to support transpilation of external libs with tree-shaking, but I don’t have enough knowledge in this area…

I’ll try to check with the webpack github, hopefully there is a way. :slight_smile: