Bug: unable to collect coverage from an extensionless JS file

[ljharb]

I have an executable JS file, with a node shebang. I want to collect coverage from it.

However, adding the explicit path to it to collectCoverageFrom does not cause it to show up in the coverage report (even as having zero coverage). How can I target this file? I also tried bin/** (which should match any file of any kind in the directory, according to how globs work), but maybe there's some kind of auto-extension logic that I can't find in the docs.

[boujeepossum]

hm.. that really depends on your configuration. The function that defines whether the file should be instrumented or not is defined here https://github.com/facebook/jest/blob/master/packages/jest-runtime/src/shouldInstrument.js

i tried it locally (you can look at this commit https://github.com/dmitriiabramov/jest/commit/7fd98e6cab6e1054dbfe95cb93f4f8a699ac87e9) and it collected coverage

[ljharb]

@dmitriiabramov in that case you're requiring an extensionless file - in my case it's the entry point. Nothing requires it.

[cpojer]

Please note this issue tracker is not a help forum. We recommend using StackOverflow or our discord channel for questions. Thank you :)

[ljharb]

Since there's nothing in your documentation that seems to cover this case, it's at best a bug in the documentation, and at worst a bug in jest's coverage.

[boujeepossum]

@ljharb how are you testing it if it's not required?

[ljharb]

@dmitriiabramov I'm not. But I still want it to show up as having zero coverage, and to count towards coverage percentages.

[boujeepossum]

@ljharb ah.. i see. Yeah, that might be a bug. we get the list of all files in the project from the haste map instance, and haste map only looks for file extensions specified in moduleFileExtensions config option. So for extensionless files it will not work out of the box. The only thing i can think of is renaming the file to .sh and adding sh to the list of module file extensions in Jest config

[ljharb]

Thanks for confirming. Adding an extension to what is an executable file would potentially break, and also certainly violates conventions. How can we fix this so that jest can address extensionless files?

Can I somehow override moduleFileExtensions to include "" (empty string), and also only for the ./bin directory?

[ljharb]

@cpojer considering this is an actual bug in jest, can this be reopened?

[boujeepossum]

yeah, adding "moduleFileExtensions": ["js", ""] to the config doesn't seem to work. @cpojer you have more context on how hastmap and watchman works. is there any other way to index extensionless files?

[cpojer]

I don't really know if this is currently fixable tbh. Is it possible to include the full filename as an extension name? We can't collect every file as it would be too slow.

[ljharb]

Maybe a config variant within collectCoverageFrom? like, instead of a string, I could also pass { extensionless: 'the normal string matcher' }, or { exact: 'path from root dir' } or something?

[rickhanlonii]

Any movement we can make on this? Otherwise, I'm inclined to add docs that say extension-less files are not supported for coverage.

[rickhanlonii]

@ljharb can you update the issue title to be formed as a bug submission instead of a help question?

[github-actions[bot]]

This issue is stale because it has been open for 1 year with no activity. Remove stale label or comment or this will be closed in 30 days.

[ljharb]

bump; extensionless files are used by almost every package that has an executable, and it’d be great to cover these.

[SimenB]

I think adding extensionless files to the hastemap should be fine - we already crawl everything, we just skip them if there's no extension.

https://github.com/facebook/jest/blob/f3c48b52ffd9086e9848d742009068c8f6d5881c/packages/jest-haste-map/src/crawlers/node.ts#L107-L110

So in theory if you could add '' to moduleFileExtensions and have it work.

Not sure how that would work with watchman, but still.

Would you be willing to try implementing this?

[github-actions[bot]]

This issue is stale because it has been open for 1 year with no activity. Remove stale label or comment or this will be closed in 30 days.

[ljharb]

bump

[github-actions[bot]]

This issue is stale because it has been open for 1 year with no activity. Remove stale label or comment or this will be closed in 30 days.

[ljharb]

bump

[github-actions[bot]]

This issue is stale because it has been open for 1 year with no activity. Remove stale label or comment or this will be closed in 30 days.

[ljharb]

bump