create-react-app-typescript
create-react-app-typescript copied to clipboard
Can't find certain modules when reloading on saved changes (watcher)
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?
Reloading, module reloading, watcher
Environment
npm ls react-scripts-ts(if you haven’t ejected): [email protected]node -v: v8.11.2npm -v: 4.6.1yarn --version(if you use Yarn): 1.7.0npm ls react-scripts-ts(if you haven’t ejected): [email protected]
Then, specify:
- Operating system: macOS 10.13.4
- Browser and version (if relevant): Chrome 67.0.3396.99 64-bit
Steps to Reproduce
Expected Behavior
I'm using create-react-ts with pixi.js (and @types/pixi.js), for using additional filters I installed the module pixi-filters, I expected everything to go well in my workflow.
Actual Behavior
Everytime I run yarn start, the build process proceeds without problems, however, when reloaded using watchers, sometimes I get Cannot find module pixi-filters, which has been installed correctly.
Because of the type definitions, I imported it as import * as filters from "pixi-filters"; instead of import filters from pixi-filters`` (not sure if this matters).
This is however, not the only module it happens to, also a custom module which we install through SSH.
When I run yarn start again, it's fixed. Might be something to do with timing?
This is my tsconfig:
{
"compilerOptions": {
"target": "ES6",
"module": "commonjs",
"typeRoots": ["node_modules/@types"],
"sourceMap": true,
"removeComments": false,
"outDir": "build",
"noImplicitAny": true,
"alwaysStrict": true,
"strictNullChecks": true,
"noUnusedLocals": false,
"noUnusedParameters": false,
"noImplicitReturns": true,
"noImplicitThis": true,
"noFallthroughCasesInSwitch": true,
"allowSyntheticDefaultImports": true,
"moduleResolution": "node",
"baseUrl": "src",
"jsx": "react",
"declaration": true,
"allowJs": false
},
"compileOnSave": false
}
Reproducible Demo
(Paste the link to an example project and exact instructions to reproduce the issue.)
Does this happen on macOS only, or on other operating systems as well?
I'm aware of several issue regarding file watching on macOS - most of them are attempted to be fixed via the fsevents package.
Since this fork does not modify the related configuration for the mode, this is more likely to be a general issue, either of the way CRA configures the watch behavior, or of the way webpack (more specifically: watchpack) behaves on macOS.
Same issue with styled-components library. Appears randomly when reloading on saved changes.
Import as: import styled from 'styled-components';
When reloading on saved changes:
Cannot find module 'styled-components'.
Operating System: Windows 10 1803 Browser: Chrome 68.0.3440.84
Hmm so this happens on Windows too..
The URL you provided is invalid by the way, can you reference the specific issue? @gregorianisch
@Fabiantjoeaon thanks, fixed the link.
For me it worked when I specified module typings out of node_modules folder. In my case under src/typings/styled-components/index.d.ts
Content of src/typings/styled-components/index.d.ts:
declare module 'styled-components' {
// Copy-paste from node_modules\styled-components\typings\styled-components.d.ts
}
Couldn't find the real cause of an issue, but this temp fix will probably help you also.
P.S. You will need to update your "typeRoots" in tsconfig.json in order to include types from directories. E.g. "typeRoots": ["./src/typings"]
@gregorianisch
I see. I think it might has to do something with the naming of the typings file?
The module in question for me is pixi-filters, I found out it uses a file called types.d.ts, and when I changed it to index.d.ts, it solved my issue, which makes sense because the TS docs say (when making use of node_modules/@types:
A types package is a folder with a file called index.d.ts
I installed styled-components to check out their typings file, and they are using a file called styled-components.d.ts inside a typings folder, changing it to index.d.ts might also fix this issue. I noticed it has been mentioned here.
So overwriting it the way you suggested might be the right fix, but you have to do it for every module, that's why I just tend to use "typeRoots": ["node_modules/@types"],
Is this the fault of the author of the modules (which seems unlikely to me?), or is it something in our configuration? Also, kinda strange that it does work when restarting yarn.