-
Notifications
You must be signed in to change notification settings - Fork 2.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
No Type Checking on initial load #1217
Comments
I'm currently encountering one of the following states though I cant reproduce them deterministically:
Also encountering with |
Yes, I think this is an issue for all TS projects right now. When you just load a sandbox there are no type errors, because the typing files haven't been downloaded yet. Only when you switch a file we start type checking. We should fix this! |
@CompuIves They should probably treated as normal dependencies when listed as such. Some more observations:
|
Agreed, but we only start downloading dependency files after the editor has been loaded, otherwise we would have a pretty big startup time. I need to find a way to trigger a type check in Monaco/VSCode after the files have been downloaded, that should be enough to make it work.
This is interesting, I tested with the experimental editor (I use this as my primary editor) and it seemed to work. Does clearing the cache work? |
Tested again (incognito window, disabled cache, disabled service worker) and now I encounter #1205 in the normal and experimental editor once typechecking kicks in. |
Hmm, so you see the red squiggles for all files? Are you still working with the sandbox mentioned in the original post? |
I switched to https://codesandbox.io/s/j4wkmo2nx3 but the original sandbox with I'm trying a local dev setup to verify that this is not some weird issue with caching or serviceWorkers. |
Oh yep! I'm having the same issue now, it happens when adding @material-ui/core. This is a problem on our side, we cancel download type files for dependencies that have more than 400 typing files to download (otherwise the editor would get laggy and lots of download). It seems that react/react-dom typings are also cancelled by this for some reason, which is really weird. I wish we wouldn't have to eagerly download type files, but as it is now the typescript language server requires us to resolve typing files synchronously, that's why we download them eagerly. I'll see what I can do to optimize this and let the typings of @material-ui/core not affect those of react/react-dom. |
This perfectly describes the issue: microsoft/TypeScript#1857 (comment) |
With a local setup on master I get no typechecking in the normal editor. The experimental editor works perfect. I would like to bundle our typings into a single file but all the packages I know don't support bundling for declaration files. I guess this can become an issue for other libraries since typescript emits declarations for every file and 400 is not that many but I totally get why you bail out. So once microsoft/TypeScript#4433 is resolved this won't be an issue. But thanks for your help. Really appreciated! |
I found a compromise where you won't be able to open the type definitions in the editor, but they will be available in the type checking! Will go live today. |
🐛 bug report
Description of the problem
No type errors are reported in the editor or console.
How has this issue affected you? What are you trying to accomplish?
On the initial load of https://codesandbox.io/s/react-ts I get type errors as well as #1205. Once I fork this I don't get type errors or the linked issue.
Link to sandbox: link
Your Environment
PROD-1540023398-4e289bd
The text was updated successfully, but these errors were encountered: