Recompilation does not happen in subfolder?

[gytisgreitai]

Is this a bug report?

Yes

Can you also reproduce the problem with npm 4.x?

Yes

Which terms did you search for in User Guide?

Failed to compile, subdirs.

Found probably related closed issue: #187

Environment

1. npm ls react-scripts-ts: react-scripts-ts@2.12.0
2. node -v: v8.2.1
3. npm -v: 5.3.0
4. yarn --version: 1.3.2

Then, specify:

1. Operating system: Mac OS High Sierra 10.13

Steps to Reproduce

1. create-react-app react-scripts-ts-non-working-subdirs --scripts-version=react-scripts-ts
2. cd react-scripts-ts-non-working-subdirs/src
3. mkdir -p whatever && cd whatever
4. echo 'window.whatever = false' > willfail.ts
5. cd .. && yarn start (same with npm start)
6. Will fail to compile (1,8): Property 'whatever' does not exist on type 'Window'.
7. Open willfail.ts in Editor (Visual studio code, Atom, Vim), comment the failing line out. Click save, nothing happens
8. Open any other file that is directly in src (eg. App.tsx, index.tsx) hit save. Compilation restarts all good

Expected Behavior

I would expect that changed to ts files in subfolders would trigger a recompile

Actual Behavior

Recompilation does not happen if there are errors and files that are in subfolder are saved

Reproducible Demo

https://github.com/gytisgreitai/-react-scripts-ts-non-working-subdirs

[kucharzyk]

I can confirm this behaviour. After error I must restart dev server.
It starts happening from version 2.10.0

Moreover dev server stops also when I have lint error in test files.
Does dev server shouldn't ignore test files?

[DorianGrey]

Regarding the recompile issue:
Webpack watches the directory for file changes and addition resp. removal of files. If a file is added or removed, this will trigger a compilation run, thus also performing a type check (see explanation of hook usage here).
This will happen even though that file is not referenced from your entry points. However, changes will only trigger a useful rebuild (and thus: a type check) if the changed file is referenced from the entry points (directly or indirectly). Otherwise, nothing will happen.

Regarding the linter:
Currently, the linter ignores nothing inside the src directory, since code quality checks shouldn't stop on test files (or should they?). Though it might be useful to change the default severity for dev mode.
If you really want some files to be ignored, it's possible to specify the linterOptions in the linter's config file tslint.json.
E.g.:

"linterOptions": { 
  "exclude": [
    "src/**/*.test.tsx",
    "src/**/*.spec.tsx",
  ] 
}

[gytisgreitai]

Ok thanks, reasoning is clear, but the behaviour is not very intuitive.

[kucharzyk]

In my opinion there is nothing wrong in linting test files by dev server but dev server should recover after fixing typo. It's not acceptable to restart dev server after fixing file. Also dev server should not compile test files - it could consume a lot of time and resources - most of time you have tests running so why double check test files?

[DorianGrey]

[...] Also dev server should not compile test files [...]

Actually, they don't get compiled, it just performs a type check. It's a bit unlikely here - jest (resp. ts-jest, as used here) is not capable of performing a type check for the test files due to the usage of transpileModule, though it's useful to have this to detect errors in your test code.

As mentioned above, the plugin that runs type checking and linting is triggered by a webpack hook, and that one does not execute for files that are not referenced via the entry points. The alternative would be to force the plugin to ignore these files, but that results in no type checking and linting for the test files without manually calling it via CLI.
Another alternative - manually watching these - was already discussed in the issue linked above, and that has even more downsides (additional watcher to maintain).