jest collect coverage from /dist/**/*.js instead of /src/**/*.ts

Describe the bug Right now in the tests, we’re doing a mix-match of import {..} ../src/... and import {..} ../dist/.. The issue with the latter is that jest coverage is set to collect from src/**/.ts. Except, there’s a very subtle and nasty bug when tests import from src folder. The state of objects that are instantiated upon module import. I ran into this hair-pulling bug in core-blockchain/src/plugin.ts and also in core-p2p/src/plugin.ts

line 4: import { config } from "./config"; line 19: config.init(options);

./config instantiates a config object when that module is loaded. Now here’s the kicker. Doing import {config} from "/src/config" counts as a different module, when compared to import {config} from "/dist/config"

If ANOTHER class imports the ./config module, the ./config shares its path too. So if you import a class with from /src/ then the ./config module will be loaded from /src/config. If you import from /dist, the ./config is loaded from /dist/config

Why is this an issue? The tests were importing & loading the tested class from src, but the jest-runner was booting up and loading classes from dist . Because those two are considered different paths/modules, they will each new up a config object resulting in two instances of the Config class. However, when later in line 19 shown above, only the config instance created by code running from /dist will have the .init method called on it. The src config instance will not. This creates a very peculiar issue where the tests will fail because, the config instance the tests refer to, hasn’t been initialized and the tests were expecting that behavior.

So we change the tests to import from dist, but now we get no coverage because jest is looking at src source files.

Since we can’t force jest-runner to boot from src, tests should be referencing dist imports(which are supposed to be the compiled sources anyway so it’s appropriate for tests to refer to them), we should change where jest is looking for coverage to dist/**/*.js. Solves both that bug, and we still get the coverage numbers, while losing readability since coverage will be based on the transpiled files, which aren’t always human-readable.

[faustbrian]

https://codecov.io/gh/ArkEcosystem/core/tree/develop/packages

[air1one]

Thanks guys for your answers. After some more investigation I think I have a solution that can make everyone happy :

Basically when we are in a package, say core-api, we just register manually the core-api plugin. This gets us typescript coverage.

Why does this work ? Because when we register manually our package, we will register the code that is transpiled by ts-jest and as this is the typescript pre-processor we use for tests it works fine.

Right now we let core-container register automatically all the packages, so basically when we’re in core-api, it registers the core-api code that’s in dist and that has nothing to do with the code we’re actually transpiling at the moment (again, this one is transpiled by ts-jest). Hence the coverage issue.

I tested on core-api package and got coverage with my solution. I will prepare a pull request and update the other packages, so you can see what I’m talking about 👍