tsdx lint errors out if you have co-located test files (i.e. no test dir)

[pcowgill]

Current Behavior

Added tsdx to a project where test files are in the same dirs as the files under test like this:

src/
  dir1/
    file1.ts
    file1.test.ts

... and ran npm run lint. This is the error generated:

Error: No files matching 'test' were found.

The linter doesn't finish running because of it.

Desired Behavior

Linter doesn't error out due to this project structure.

Suggested Solution

Since this is a common project configuration to ensure you have a test suite per file, either edit the default configuration to support this setup or add a flag to tsdx create or tsdx lint that supports it.

Who does this impact? Who is this for?

All users, potentially. Specifically, people who have their test files next to their files under test in their dir structure.

Describe alternatives you've considered

• A tsdx eject command that lets you override these settings (sort of against the spirit of the project, though)
• Stopping writing tests with this style (but the benefits outweigh the costs)

Additional context

[pcowgill]

Having looked more closely at the lint command, it appears that modifying the lint script in my package to "lint": "tsdx lint src" achieves what I want here. So maybe this issue just can be about documenting that in the main README?

[skvale]

If you look at the output of tsdx lint, it does provide a warning immediately above the error:

No input files specified, defaulting to src test
Error: No files matching 'test' were found.

Do you think that warning should suggest something more verbose?

No inputs were passed to lint, it defaults to run on "src test".
If this doesn't work, you can override the lint command in your package.json scripts like "lint": "tsdx lint src"
Error: No files matching 'test' were found.

[pcowgill]

Yeah, since the value prop of tsdx is zero config like prettier, create-react-app, etc., I assumed it wouldn’t error out for a pretty common setting, and I assumed I wouldn’t have to edit the scripts in package.json this early on.

So I think it should more gracefully handle this case by default, and if not that, then putting actionable advice on how to fix the error like in the example output you gave above would be great.

This project is very well done - I’m a big fan! Keep up the good work. Hopefully I’ll open a PR or two sometime soon.

[arthurdenner]

@pcowgill, once this PR gets merged, we can change the behavior.

[pcowgill]

@arthurdenner Perfect, thanks!