test/ dir is in `include`, non-spec TS files (e.g. test utils) break build with v0.13 rootDir: `./src`

[lookfirst]

Current Behavior

Prior to v0.13 #504 , I could put a file into my test folder that contained utility code for tests and it would get compiled without a problem.

test/TestUtils.tsx

Now, when I tsdx build, I see this error:

rpt2: options error TS6059: File '/mui-rff/test/TestUtils.tsx' is not under 'rootDir' '/mui-rff/src'. 'rootDir' is expected to contain all source files.

Expected behavior

I have a place to put utility code for tests.

Suggested solution(s)

No idea, but you have a list of 3rd parties using this project and it would be nice if you would start to test future versions of tsdx against these projects to see if you break peoples stuff and can then use that to find out how to tell people how to fix their broken stuff.

Your environment

Software	Version(s)
TSDX	v0.13
TypeScript	3.8.3
npm/Yarn	6.13.7 / 1.22.4
Node	v13.11.0
Operating System	OSX Catalina

[agilgur5]

You don't need to (and probably shouldn't) compile it during build if it's just test code (the error says "source files" and this is a test file), you can just import it in your tests and ts-jest will handle it fine.

EDIT: for tl;dr for other readers, remove "test" from your tsconfig.json include similar to what the templates in v0.13.1 have:

tsconfig.json:

{
  "include": ["src", "types"],
   // ...
}

to see if you break peoples stuff and can then use that to find out how to tell people how to fix their broken stuff.

It is listed very clearly as a deprecation in the release and clearly prints a warning. I very much know it can break many people's code, that is the exact reason it is a deprecation with a warning instead of a full breaking change.

The warning says the previous behavior was very buggy (so much so that the more tests we added, the more frequently CI would fail) and tells you how to change. This was a necessary change.

I also do know a good number of the TSDX configs out there, but there are thousands using this, it's impossible to test against all possible uses. I did create #627 recently however.

In the future we could more formally test against some big projects, but keep in mind TSDX is still very young, it is v0.x and will still have many breaking changes ahead. The API surface will evolve and the point of v0.x is to make that clear to consumers that it's still being ironed out and breaking changes will happen more frequently.

Not that it's necessarily a good thing, but plenty of stable v1+ libraries much bigger than TSDX accidentally break things in patches, minors, etc (this occurs in some of TSDX's own dependencies no less like in #511) or make very hard breaking changes that require big migrations. But that'll happen, and every project will fix bugs and learn.

[lookfirst]

You don't need to (and probably shouldn't) compile it during build if it's just test code, you can just import it in your tests and ts-jest will handle it fine.

It doesn't 'handle it fine', hence this issue.

[agilgur5]

It doesn't 'handle it fine', hence this issue

You clearly wrote this issue is about tsdx build with an error message from build. I said you don't need to build test files. You did not mention tsdx test in your issue what-so-ever.

[lookfirst]

tsdx build is failing for me because I have a file in my test directory called test/TestUtils.tsx.

[agilgur5]

Like I said, you don't need to build that file.

I think I see what the issue is though -- the default template include contains the test dir. That should either be removed (I don't use it like that) or added to the default exclude for builds: https://github.com/jaredpalmer/tsdx/blob/e84e8d654c8462b8db65a3d395e2a4ba79bf1bd2/src/createRollupConfig.ts#L151-L162

That also meant test files were being read by rpts2/TS before and excluding them might improve performance of build a bit (.spec and .test were added to excludes in v0.13 as well).

Related to #464 / #472

[lookfirst]

I do notice that the build is faster now. =)

[lookfirst]

If I remove test folder from include and put TestUtils.tsx back into test, then I get other errors around that file. =(

[lookfirst]

Error:(6, 35) TS6059: File '/test/TestUtils.tsx' is not under 'rootDir' '/mui-rff/src'. 'rootDir' is expected to contain all source files.

[agilgur5]

Huh, even when it's not imported by any src/ files?

Not sure if that's because of an upstream bug like https://github.com/ezolenko/rollup-plugin-typescript2/issues/211 or if it's because rpts2's Rollup include passes all *.ts files in. I'll have to play around with it and see how tsc behaves. Maybe we'll have to exclude test (and __tests__) from build in any case.

You can also override TSDX's default exclude with your own exclude in tsconfig.json. Keep in mind you'll have to add node_modules and dist as the defaults do in the code linked above.

EDIT: when "test" was removed from include, tsdx build stopped giving errors and this was indeed resolved. The error OP listed above is apparently not from tsdx build but from the IDEA IDE, which OP did not mention until much later...

[lookfirst]

Yea... just try making a non-test file that is only included by test files (and not used by anything in src) work. ;-)

[agilgur5]

ok so I created a test dir with one file in it testUtil.ts and it:

1. Errors once per build format when include has test.
2. Does not error when include only has ['src', 'types'] (annnd turns out the tests all use a tsconfig.json that doesn't include test so I had to add it there)
3. Does not error when include has test, and exclude has **/test/**

So either of the workarounds work. Now the question is whether to change the default exclude or remove test from include...

include also interacts with the linter; without test there, you'll need a separate tsconfig.json for linting, which is suboptimal. I've also seen the pattern of having test (or __tests__) dir inside of src/, so a default exclude would be helpful for that pattern too. This would be a performance improvement too, not including files that don't need to be built.

Buuut, it seems that tsc --noEmit, useful for type-checking, will error out regardless if rootDir is ./src, and will do so for any .ts file in test... 😕 Removing test from include means that it won't be type-checked by tsc --noEmit either, which we don't exactly want. Could do something about both of these with the build exclude as a quick fix...

I also found https://github.com/microsoft/TypeScript/issues/9858, which validates that rootDir is only meant to control the structure of outDir (exactly how it's being used). In https://github.com/microsoft/TypeScript/issues/9858#issuecomment-370537216, says "Which files are part of your compilation is a separate question that is answered by files and/or include/exclude", so we shouldn't have test since it's not compiled. But it does need to be type-checked and linted, and it might interact with storybook too...

But it also says in https://github.com/microsoft/TypeScript/issues/9858#issuecomment-533621663 that "[include and rootDir] don't interact: The settings do not affect each other at all." which seems to be quite inaccurate as rootDir throws an error if it's not the include directory or parent of all include directories...

Guh, I'm not sure there's an easy way of reverting #504 without introducing bugs. The only way it'd work is if all package.json main, module, etc were changed to dist/src/ (which is super breaking) or we handled it internally with a tsdx publish command

[agilgur5]

Please ignore the previous comment I made (now deleted), made too many changes at once, so I tested it wrong. rootDir: ['./src', './test'] doesn't work if ./test is also in your include. If it's excluded it will though.

https://github.com/typescript-eslint/typescript-eslint/issues/1350#issuecomment-567001425 also points to using a separate tsconfig.eslint.json (which is what I do) to include files that shouldn't be compiled but should be linted.

Notably this means that for #639 , example wasn't previously linted at all, because it wasn't in your (or the default) include and was only linting TS. Same is true for storybook or in general files outside of include.

Probably want to move to using tsconfig.eslint.json in any case.

[lookfirst]

Thanks for all your work on this. It is painfully clear to me that nobody writes tests. ;-)

[agilgur5]

I understand you're half-joking, but just to respond to that:

1. TSDX is tested. But only build and lint right now. We don't have proper code coverage (I'm working on that), but the core is pretty high actually. For my part, nearly everything I've written or reviewed has had tests with the PR or in a subsequent PR. I may have written more tests than code, especially after #627.

   504 was certainly tested, in fact it made all the tests pass all the time, instead of increasingly failing.

2. TSDX is infinitely configurable though. tsconfig.json, eslintrc, babelrc, jest.config.js, tsdx.config.js all configure it and just tsconfig.json itself has an infinite number of combinations. A metric like code coverage doesn't account for that. I would like to clamp down on those a bit more with #634 and #635, which would also allow for better testing by splitting things up. The oversight here is that the test fixtures aren't a 1-to-1 match with the templates, as I realized above. (create is also a young feature (with no tests yet) with mostly community contributions. e.g. #226 added the test include, Storybook is entirely community contributions and is very recent). The question I've been trying to answer here is which is wrong -- the test or the template (or both). Given #504 was necessary and that these issues I've linked to point to some different methods of configuration, it might be that the templates should be changed. Problem is that both configs are valid, but which one is better long-term and more the norm. And that TSDX still needs to be backward-compatible to support old configurations

3. tsconfig.json in particular has a TON of confusion around it as the issues I've linked above show and as have previous issues with it (like paths support). The TS community has used features differently than they were originally intended to be used and there has even some confusion from TS maintainers. This is partially due to tech debt, with many historical decisions as the JS ecosystem evolved and a need to stay backward-compatible.

4. TSDX is still young. See my initial comments -- still v0.x There's a lot to work on, much of the things I mentioned here are config and test related, which are the key issues you're pointing to.

[lookfirst]

For the record, I wasn't poking at TSDX, I was poking at users of TSDX. ;-)

[lookfirst]

If your users were writing tests, I'd expect to see a long list of people commenting on this issue right now.

Having a simple helper file that is shared between tests is such a common usecase in every set of tests I've ever written, it seems to reason that people would be commenting like mad right now.

[jaredpalmer]

This is a bad bug. It is also preventing Formik from using latest release. We need to fix this ASAP, lots of folks have test utils in separate files, definitely falls under 80% of all TS projects IMHO.

[jaredpalmer]

Thank you both for the back and forth.

[agilgur5]

If your users were writing tests, I'd expect to see a long list of people commenting on this issue right now.

Ah, I see. Well I think there's also less because not everyone has upgraded, and not everyone has test in their include.

So I did some more testing -- having test in the include had other problems already (with rootDir: './'): tsdx build would output type declarations for files in test just like #464 / #472 . They didn't need to be co-located, they just had to be inside the include.

472 made it so the .spec and .test files didn't have type declarations generated for any include in general (incidentally that was from my review, it was initially only for src/**/* specs), meaning it helped with test include part too.

---

So I think the correct approach to this will be to remove test from include in the templates, i.e. revert #226, as that was buggy already, and issue guidance on that. The config that makes the most sense actually is files: ['src/index.ts'] as that's the only file that's built. Could include types as well.

Notably tsc --noEmit for type-checking (which might mirror type-checking in the editor integration too; not sure mine is quite configured) and tsdx lint do need to include all TS files so that they're all type-checked and linted. Linting isn't too difficult, we just create a tsconfig.eslint.json that extends the base but instead include: ['**'] or something, and use it in the default parserOptions. That should be added to --write-file too. (this is basically what I use in my libraries) Type-checking and editor type-checking are more difficult; while tsc -p can be used to choose a tsconfig.json, the editor might only use the exact tsconfig.json of the directory -- see #84

That's super involved, though notably example and stories weren't linted or type-checked beforehand anyway; practically speaking it only changes how test is handled (and ts-jest already type-checks anything that's imported there as well). EDIT: example would be type-checked by an editor because it has its own tsconfig.json (differently configured, c.f. #538), but not with tsc --noEmit from root. example TS files weren't linted because the root tsconfig.json didn't include it

A quick-fix that handles this particular case is the suggestion I made before, adding test/ to the default exclude. That's more like a band-aid though, the actual issue is that test/ shouldn't be in include The quick correct solution is to remove it from include, and then we can focus on configuring everything else after, which involves a lot more changes.

[agilgur5]

It is also preventing Formik from using latest release

Also they are just warnings, you can ignore the rootDir warning and continue using ./, just that that usage breaks declaration maps and might occasionally fail to produce all declaration files as we had on CI (you also called that "a BAD bug" 😅 , it's arguably worse since it's silent if you don't have a test for it).

[agilgur5]

Type-checking and editor type-checking are more difficult; while tsc -p can be used to choose a tsconfig.json, the editor might only use the exact tsconfig.json of the directory -- see #84

So maybe it makes sense for root tsconfig.json to have include: ['**'] for linting and type-checking via tsdx lint and tsc --noEmit as well as zero-config editor integration. And then we have a tsconfig.build.json that's specifically for building, has file: ['src/index.ts'] and maybe include: ['types/'] and would be used by default by tsdx build. tsconfig.json could extend tsconfig.build.json so that it's the source of truth.

Not sure how Storybook would interact with this however, c.f. #641

[agilgur5]

Confirmed some more cases today that the faulty include of test affects existing libraries:

• mobx-react has test/**/* in their include and published with a test dir in 6.1.8. That's actually not from our templates, which confirms that is a wider spread issue in the TS community in general (and they're certainly more experienced in TS than me, mobx and MST have some crazy types -- immer uses files: [...] instead though).
• mui-rff, which I think is based off our templates (correct me if I'm wrong) and uses test in include, had published a test dir in 2.0.3 and prior, but not in 2.0.4 which uses TSDX v0.13
• The test dir just has type declarations, but those shouldn't be published, and it's wasteful for rpts2 / TS to process the test dir and then compile out declarations. Hence, removing it will also improve performance.

So yea, having test in include confirmed to be problematic a few times now and confirmed to be a wider TS community issue.

It is also preventing Formik from using latest release.

@jaredpalmer I checked out Formik and am not sure what the issue is there, as Formik doesn't have test in include. Doesn't seem like Formik should have any problems with changing rootDir to ./src, but let me know if I'm missing something

---

Currently working on getting #621 and #627 out ASAP as they improve testing and the testing structure. Then will push out two PRs with tests, one for an initial quick-fix of removing test from the templates' include, and a second for using the tsconfig.build.json with file: ['src/index.ts'] and a tsconfig.json with include: ['**']. Will need to test at least the latter with Storybook as well. Planning for the first to land as v0.13.1 and the second ideally v0.13.2 (although it's a big change idk, requires an internal change in tsdx build to support tsconfig.build.json as the default too). Should also group nicely with planned changes for v0.13.x around noEmit (only for tsconfig.json, not tsconfig.build.json), skipLibCheck, removing redundancies, improving the example tsconfig.json, and adding comments to various tsconfig options to help with understanding why we configured them as such. Some of those could go out before the tsconfig.build.json change, though that ties into why removing test from include in v0.13.1 is necessary

A preset for tsconfig.json, as part of #634, would also be something helpful to expedite to make future changes to it easier. The custom templates PRs give me some concern about allowing other templates out there that might currently use incorrect configuration too

[lookfirst]

• mui-rff, which I think is based off our templates (correct me if I'm wrong) and uses test in include, had published a test dir in 2.0.3 and prior, but not in 2.0.4 which uses TSDX v0.13

It is based off a template several versions ago.

[agilgur5]

Removed from the template, test added, and added a sentence to the rootDir deprecation warning about this in #646

Per my comments there, I couldn't reproduce the VS Code issues in #225 / #80 and tsdx lint continued to work fine. Though tsc --noEmit indeed stopped reporting errors in test. Opened an issue around creating integration tests for VS Code in #650 -- not totally sure how to do that myself.

@allcontributors please add @lookfirst for bug

[allcontributors[bot]]

@agilgur5

I've put up a pull request to add @lookfirst! :tada:

[lookfirst]

Updated to latest version (0.13.1)

I moved my TestUtils.tsx file from ./src back to ./test. Removed 'test' from include in tsconfig.json.

Now my IDE reports this error:

"TS6059: File '/mui-rff/test/TestUtils.tsx' is not under 'rootDir' '/mui-rff/src'. 'rootDir' is expected to contain all source files."

[agilgur5]

Yea you gotta remove test from your tsconfig.json include: https://github.com/lookfirst/mui-rff/blob/e8519273740ac48f217b232d8dcd7e1cf606a659/tsconfig.json#L5

v0.13.1 just changed the templates, unfortunately we can't change user tsconfigs yet (but maybe we will once there's a TSDX tsconfig preset)

[lookfirst]

I did remove it.

[lookfirst]

I just undid my changes. Not only did it also not work, but it started to give me some other weird issues around typings with the date-io library in tsc output.

tsc
node_modules/@material-ui/pickers/typings/date.d.ts:1:26 - error TS2307: Cannot find module '@date-io/type'.

1 import { DateType } from '@date-io/type';
                           ~~~~~~~~~~~~~~~

node_modules/@material-ui/pickers/views/Year/YearView.d.ts:2:26 - error TS2307: Cannot find module '@date-io/type'.

2 import { DateType } from '@date-io/type';
                           ~~~~~~~~~~~~~~~

[lookfirst]

Feel free to clone my repo, fix what you think is broken and make sure to open a test file in IDEA and make sure nothing is broken there too. Then submit a PR. Then you could close this issue. ;-)

[agilgur5]

Ok, might wanna restart your IDE or something, I have periodic caching issues in mine too.

If your include doesn't have test, TS literally doesn't pick it up at all, like tsc --noEmit doesn't even read it.

So either cache issue or there's a bug in the IDE

[lookfirst]

I did clear cache and restart it.

[agilgur5]

I mean I don't know what to tell you, that sounds like an IDE issue -- it's reading your test dir despite that not being included (only other way it'd be included is if you imported it from an included file, which it doesn't seem like you're doing).

If tsc doesn't read it and doesn't error, neither should the IDE. (You might wanna throw in --skipLibCheck for simplicity, though the @date-io/type error is an error in your dependencies)

[lookfirst]

You might wanna throw in --skipLibCheck for simplicity

tried. no difference.

, though the @date-io/type error is an error in your dependencies

Mind sharing why you think that? It works fine with 0.13.0 and broke with 0.13.1.

[agilgur5]

Mind sharing why you think that? It works fine with 0.13.0 and broke with 0.13.1.

I mean, it's literally coming from your dependencies, that's got nothing to do with TSDX.....

Not to mention there are essentially 0 source code changes in v0.13.1. Per the Release Notes, the most meaningful change is to the templates and testing. The only actual source code changes were to:

1. slightly modify a log statement
2. remove commented out code
3. change some internal variable names

That's it. Period. Can see the changelog yourself.

It's probably when you updated dependencies something else got updated and now your node_modules is different.

In any case, this isn't a TSDX error (you were getting that error with tsc for one thing) and isn't a result of changes to TSDX either, so this is now asking for support/help with your library and not TSDX issues.

[lookfirst]

Come on... you didn't believe this was an issue to begin with and now I'm trying to tell you that there is still issues and you still aren't believing me. 👎

tsdx is the only dependency changed.

I moved my TestUtils.tsx into test

I removed "test" from include.

I've uploaded the branch so you can see the changes for yourself.

https://github.com/lookfirst/mui-rff/tree/tsdx-0131 https://github.com/lookfirst/mui-rff/compare/tsdx-0131

Try opening it up in IDEA too, then open up Autocomplete.test.tsx and you can see the problem there. Maybe it is an IDEA problem, maybe it isn't... but before this change, I didn't have any problems.

[agilgur5]

Come on... you didn't believe this was an issue to begin with

I mean no, what I said at the beginning was that the problem is in your include (that you don't need to compile 'test/') and that was indeed the problem. I just didn't realize the templates had the same problematic include and that the test tsconfig is apparently slightly different than the template tsconfig.

It's not a problem in the actual source code, it's a configuration problem. I've changed the problematic template configuration.

I admit that I was wrong in that I didn't know the template was buggy, but that is a config change, meaning it needed to change in your config too, not from TSDX's side. That's why it was marked as a big deprecation at the top of the Release Notes and why it gives a warning (and isn't a full breaking change) -- it requires user-side changes.

And not for nothing, but you've made several abusive comments to several maintainers and contributors of TSDX, so I'm quite wary of interacting with you in general... (those comments would also be against mui-rff's own CoC)

https://github.com/lookfirst/mui-rff/compare/tsdx-0131

Yea so look at your yarn.lock changes -- TSDX is literally only 3 lines of 400+ lines changed in it. yarn upgrade unfortunately does not just upgrade one dependency, it upgrades lots. It's better to just change the dependency version if your package.json and run yarn install.

Notably, when you run yarn on that branch, it auto-removes a bunch from the yarn.lock -- you definitely have some inconsistencies. EDIT: Annnnd turns out when I run yarn on master, then tsc --outDir dist/ (after removing 'test/' from include), I get the same exact error with the @date-io/type thing -- that existed before you even updated to v0.13.1... And the error on @date-io/type, is not exactly an uncommon issue: https://github.com/mui-org/material-ui-pickers/issues/1074 Not sure why I'm doing all this and looking this up for you though...

Not to mention it's pretty easy and quite common to have a stale node_modules as it's unversioned.

Again there were essentially no source code changes in v0.13.1, so there's nothing it could have broken.

Try opening it up in IDEA too, then open up Autocomplete.test.tsx

I don't use IDEA, but it opens fine in VS Code. No "Problems" (that's the term in VS Code) are reported in tsconfig.json or in Autocomplete.test.tsx.

Also if you had 'test/' in your include, tsc would give the rootDir error on every single test file, not just on test/testUtils.ts (tsdx build has a default exclude, which is why it differs from plain tsc)

[lookfirst]

And not for nothing, but you've made several abusive comments to several maintainers and contributors of TSDX, so I'm quite wary of interacting with you in general... (those comments would also be against mui-rff's own CoC)

I am direct and I am honest, I don't apologize for that. I disagree on abusive, but whatever. As for wary, I'd expect you to treat any bug report like a bug report... it isn't a personal thing... right?

yarn upgrade

I didn't run yarn upgrade. I ran yarn upgradeInteractive. I've found them to do different things.

Notably, when you run yarn on that branch, it auto-removes a bunch from the yarn.lock -- you definitely have some inconsistencies.

That is interesting, but it looks like it is just yarn cleaning up itself. This 'inconsistencies' is yarn's own issues, not mine, since all I did was run yarn upgradeInteractive and check things in.

It also doesn't fix the issue to run yarn...

EDIT: Annnnd turns out when I run yarn on master, then tsc --outDir dist/ (after removing 'test/' from include), I get the same exact error with the @date-io/type thing -- that existed before you even updated to v0.13.1...

I don't understand your logic. I run yarn on master and it doesn't change anything in the lock file and now you're changing things related to 0.13.1 on master, which isn't even using 0.13.1.

Again there were essentially no source code changes in v0.13.1, so there's nothing it could have broken.

essentially

I don't use IDEA, but it opens fine in VS Code.

So this tool only works with VS Code? Maybe you should publish that as a requirement on the README.

[lookfirst]

FYI, adding skipLibCheck: true is a workaround for the date-io stuff...

[lookfirst]

Let's see what IDEA says about it: https://youtrack.jetbrains.com/issue/IDEA-236281

[agilgur5]

I am direct and I am honest, I don't apologize for that. I disagree on abusive, but whatever.

Making personal attacks, for one thing, is against your own CoC, and I'm certainly not the only one who thinks those are abusive behaviors. I'll leave it at that.

This 'inconsistencies' is yarn's own issues, not mine, since all I did was run yarn upgradeInteractive and check things in.

I mean that's not "yarn's own issues", it affects your dependencies, changing node_modules and yarn.lock.

I run yarn on master and it doesn't change anything in the lock file

Sorry, I could've been more clear on this. I ran yarn on master because I changed branches from your v0.13.1 one, so I meant that I made sure I was running the same dependencies as fresh checking out master. Might have made it more confusing by adding that detail.

now you're changing things related to 0.13.1 on master, which isn't even using 0.13.1

Again, there are no source code changes in v0.13.1, it only changed the templates. Removing "test" from your include doesn't require upgrading.

Again, if you checkout master and remove "test" from your include, then run tsc --outDir dist/, you get the same @date-io/type error. This is also a common, unresolved problem with @material-ui and I linked an issue that has other linked issues that are all unresolved.

essentially

Yea this is unhelpful, out-of-context, and passive-aggressive, like your past comments.

I listed exactly what the source code changes were and again, you can check the diff yourself. You expected me to checkout your source code but didn't seem to even read a short list.

Again, changing a log message, removing comments, and changing the name of an internal variable does not impact your code. And once again, your @date-io/type error has nothing to do with TSDX, is a common error with the libraries you're using, and you were getting that error before upgrading to v0.13.1 anyway.

So this tool only works with VS Code? Maybe you should publish that as a requirement on the README.

Your IDE is your IDE, that's an integration. It also sounds like your IDE has some bugs in it. TSDX does advertise "play[ing] nicely with VS Code", so that is an integration that is a priority to work with (integrations are generally not high priority in most libraries, however). It still doesn't work great out-of-the-box in VS Code even despite the advertisement, as you know yourself.

I created #650 to track that. You're welcome to contribute code and tests for TSDX to work better out-of-the-box in your IDE as well, though it sounds like a bug in your IDE. Out-of-the-box config for every IDE and every extension cannot really be a high priority for any project. In any case, that's a separate issue around that specific integration; we've resolved the problems with tsdx build/the template tsconfig.json, and that even has tests for it now.

---

Locking this as it's now off-topic and abusive. I went through the significant effort of checking out your library, which has clear issues in its dependencies, ran several tests with it, and pointed out exactly what those exact issues were in the deps, and then received abusive comments back instead of thanks.

[agilgur5]

Let's see what IDEA says about it: https://youtrack.jetbrains.com/issue/IDEA-236281

You should probably give them your tsconfig.json as well -- it doesn't include "test" but you're getting an error for things in "test" (and that error itself says "all source files").

And, per previous comments, for some reason only one file is giving that error instead of all "test" files (tsc would give errors for all if the include had "test"), which makes it seem even more like a cache issue.

[agilgur5]

You can also use the approach I mentioned in https://github.com/jaredpalmer/tsdx/issues/638#issuecomment-603512948 , which should make the tsconfig.json work better with all sorts of integrations, but per above, I haven't been able to repro the reason why "test" was in include anyway, so I'm not officially recommending that yet or adding internal changes (especially as it's a relatively big change to user configs).

Summary would be:

• tsconfig.json -> tsconfig.build.json (optionally remove "src" from include and use files: ["src/index.ts"] as a safelist instead... though this apparently has some bugs in upstream rpts2)
• new tsconfig.json:

{
  extends: ['./tsconfig.build.json'],
  include: ['./'], // all files should be checked
}

That'll require passing --tsconfig ./tsconfig.build.json to tsdx build for now. If it's officially adopted, tsconfig.build.json will be read first, with tsconfig.json as back-up if it doesn't exist.