Open dillondotzip opened 3 years ago
flybayer
commented
3 years ago Thanks @dillonraphael. Someone else mentioned this too I think.
Have you tried any versions in between? That would be very helpful, especially to test 0.34.0 as that's the only release I can think of that has significant change to types. It upgraded RQ from v2 to v3 and also added our Route Manifest.
flybayer
commented
3 years ago This might show up in the terminal with yarn tsc, but need to disable the incremental tsconfig flag to be accurate.
dillondotzip
commented
3 years ago Thanks @dillonraphael. Someone else mentioned this too I think.
Have you tried any versions in between? That would be very helpful, especially to test 0.34.0 as that's the only release I can think of that has significant change to types. It upgraded RQ from v2 to v3 and also added our Route Manifest.
Just tested with 0.34.0, and still having issues. Also, there still might be performance issues when extending the .eslintrc.js file with blitz v0.33.0 - though I cannot confirm consistency compared with the newer versions.
module.exports = {
extends: ["blitz"],
}Part of me thought I was going crazy and seeing things. But the difference between the latest blitz project versus the v0.33.0 project is greatly noticeable.
flybayer
commented
3 years ago Ok thanks. So perf with 0.37 and 0.34 is pretty much the same? Pointing to 0.34 as the issue? At least this is working starting thesis I think.
The eslint config shouldn't affect TS performance, but who knows
dillondotzip
commented
3 years ago Yes that's correct.
I found a solution in the meantime.
Inside vscode, you can goto Settings > Extensions > Typescript and look for TypeScript › Tsserver: Max TS Server Memory
I set this from 4072 to 9072
grnwld
commented
3 years ago What TS version is your VS Code using?
I had similar issues with Zod and Typescript 4.3.2. I set VS Code (.vscode/settings.json) to use workspace's TS version (4.2.4 for me). Instant fix for me.
maxfi
commented
3 years ago I'm also experiencing this issue. Very slow intellisense / errors / autocomplete in vscode. I've occasionally also found that some query results will incorrectly show as type any.
Dependencies:
"dependencies": {
"@tmcw/togeojson": "4.4.1",
"@tozd/random-id": "1.0.0",
"abnacn-validator": "0.0.5",
"async-wait-until": "2.0.7",
"blitz": "0.38.5",
"concurrently": "6.2.0",
"formsy-react": "2.2.5",
"formsy-semantic-ui-react": "2.1.2",
"geojson-geometries-lookup": "0.5.0",
"iframe-resizer": "4.3.2",
"logrocket": "1.3.0",
"mailgun-js": "0.22.0",
"mongodb": "3.6.10",
"node-nab-api": "1.0.0-rc.2",
"quirrel": "1.6.2",
"react": "alpha",
"react-dom": "alpha",
"react-geosuggest": "2.14.1",
"react-signature-pad-wrapper": "1.3.0",
"remeda": "0.0.28",
"semantic-ui-css": "2.4.1",
"semantic-ui-react": "2.0.3",
"upper-case-first": "2.0.2",
"uuid": "8.3.2",
"xmldom": "0.6.0",
"zod": "3.5.1"
},
"devDependencies": {
"@types/mailgun-js": "0.22.12",
"@types/mongodb": "3.6.20",
"@types/react": "17.x",
"@types/react-geosuggest": "2.7.13",
"@types/uuid": "8.3.1",
"@types/xmldom": "0.1.31",
"cloc": "2.8.0",
"eslint": "7.x",
"file-loader": "6.2.0",
"husky": "6.x",
"lint-staged": "10.x",
"prettier": "2.3.2",
"pretty-quick": "3.x",
"ts-to-zod": "1.3.0",
"typescript": "~4.3",
"typescript-plugin-css-modules": "3.4.0",
"url-loader": "4.1.1"
},Blitz output:
$ blitz -v
Linux 4.15 | linux-x64 | Node: v14.15.1
blitz: 0.38.5 (global)
blitz: 0.38.5 (local)
Package manager: yarn
System:
OS: Linux 4.15 Ubuntu 18.04.5 LTS (Bionic Beaver)
CPU: (4) x64 Intel(R) Xeon(R) Gold 6140 CPU @ 2.30GHz
Memory: 1.24 GB / 7.79 GB
Shell: 4.4.20 - /bin/bash
Binaries:
Node: 14.15.1 - ~/.nvm/versions/node/v14.15.1/bin/node
Yarn: 1.22.5 - /usr/bin/yarn
npm: 7.5.4 - ~/.nvm/versions/node/v14.15.1/bin/npm
Watchman: 4.9.0 - /home/linuxbrew/.linuxbrew/bin/watchman
npmPackages:
@prisma/client: Not Found
blitz: 0.38.5 => 0.38.5
prisma: Not Found
react: alpha => 18.0.0-alpha-464f27572-20210713
react-dom: alpha => 18.0.0-alpha-464f27572-20210713
typescript: ~4.3 => 4.3.5tsconfig.json
{
"compilerOptions": {
"target": "es5",
"lib": ["dom", "dom.iterable", "esnext"],
"baseUrl": "./",
"allowJs": true,
"skipLibCheck": true,
"strict": true,
"strictNullChecks": true,
"forceConsistentCasingInFileNames": true,
"noEmit": true,
"esModuleInterop": true,
"module": "esnext",
"moduleResolution": "node",
"resolveJsonModule": true,
"isolatedModules": true,
"jsx": "preserve",
"incremental": true,
"tsBuildInfoFile": ".tsbuildinfo",
"plugins": [{ "name": "typescript-plugin-css-modules" }]
},
"exclude": ["node_modules", "**/*.e2e.ts", "cypress"],
"include": ["next-env.d.ts", "**/*.ts", "**/*.tsx"]
}It's a decent size project but I wouldn't expect Typescript to not be able to handle it:
$ npx cloc --vcs git
164 text files.
164 unique files.
15 files ignored.
github.com/AlDanial/cloc v 1.90 T=0.10 s (1600.4 files/s, 105420.8 lines/s)
-------------------------------------------------------------------------------
Language files blank comment code
-------------------------------------------------------------------------------
TypeScript 136 922 473 7940
JSON 8 0 0 515
Markdown 3 58 0 168
CSS 2 5 14 81
JavaScript 5 5 5 79
Bourne Shell 2 2 0 9
-------------------------------------------------------------------------------
SUM: 156 992 492 8792
-------------------------------------------------------------------------------I've tried (without success):
typescript@4.2.4 and zod@3.2@builtin onesTypeScript › Tsserver: Max TS Server Memory. Looking at the vscode Process Explorer it appeared that typescript wasn't using anywhere near the max size. The CPU would consistently sit on 25-50% for around 5 seconds after any edit to a file.Any ideas what else I could try to troubleshoot this?
flybayer
commented
3 years ago I suffered through the slow typescript issue as well. It was related to zod. Thanks to some good folks here, this sorted it for me. This is what I have so far.
"blitz": "0.38.0", "typescript": "~4.3", "zod": "3.2.0",
Extra-Extra-Dev
commented
3 years ago I suffered through the slow typescript issue as well. It was related to zod. Thanks to some good folks here, this sorted it for me. This is what I have so far. "blitz": "0.38.0", "typescript": "~4.3", "zod": "3.2.0",
I'm working with this configuration and after a day or two playing around -- I don't think it's the magic bullet. I just completed an A/B test with a small prisma.schema and a larger (~100 classes(?)) schema... and that's when responsiveness goes way out the window. ... and specifically .. you can notice the rebuilding/scanning effect on the CPU after you click around on your page after about 10 seconds after loading . Suuuuuuuper slow. Shorten the schema (luckily I can do this at this point in my development), and code helping/completion comes back to life and is fast. I don't think this issue can be looked at without also looking at the depth/complexity of the reported projects and schema sizes - edit: (at least as a way to quickly affect the authoring experience)
EDIT: I just mucked around a bit more. While using a large prisma.schema (which seemed to amplify the problem). I now downgraded typescript to 4.2.4(as noted further up in the thread) and now the development environment is responsive, With all the reading of Zod@3.2.0 being compatible with TS@~4.3.... I can't say I believe it's true.
flybayer
commented
3 years ago So sounds like maybe Prisma is the culprit here?
Extra-Extra-Dev
commented
3 years ago Well absolutely. --- or a missed item in testing the TS+Zod version issue ticket.
Larger description in our new thread: https://discord.com/channels/802917734999523368/872521899752710225/872767263151915018
snip
flybayer — Yesterday at 6:37 PM like is perf still slow in files that use prisma but not zod?
Martin.Petersen.EHV Not exactly. Typescript definitions/code-completions/highlighting is slow across all pages, regardless of code-content of the page. One of my test pages _app.tsx does not refer to db or any classes from it, nor any Zod code. But, still is painfully, crawling, slow in performance* -- when I have a large schema. Then speeds up when small schema. Thus I think it was missed as a load-factor in testing (as it was never really mentioned with A/B of your TS+Zod ticket)
.... more in thread.
fleck
commented
3 years ago https://youtu.be/wpgKd-rwnMw?t=1713 (may not be the issue, but I wonder if we're hitting a lot of turtles due to heavy use of recursive types)
Extra-Extra-Dev
commented
3 years ago https://youtu.be/wpgKd-rwnMw?t=1713 (may not be the issue, but I wonder if we're hitting a lot of turtles due to heavy use of recursive types)
Well I've certainly been reading about the changes (regarding recursion specifically) in the different releases -- so that's been a on my radar. Maybe there is a bomb in my schema that I've not seen/haven't found yet. (would be odd at this point, though, so maybe depth?)
Gonna take me some time but I'll tear that down until i find something ,,,, or not.
fleck
commented
3 years ago @Extra-Extra-Dev Since I've started using blitz vscode intellisense has always been slow, no matter what version of TS I'm using. How many lines is your generated node_modules/.prisma/client/index.d.ts file? Mine comes in at a hefty 33505 lines....
flybayer
commented
3 years ago @fleck how does TS perf in blitz compare to a nextjs or other node app with equivalent prisma schema?
fleck
commented
3 years ago @flybayer it's really snappy in vanilla nextjs. Also, in my Blitz app, I changed db/index.ts to
// import { enhancePrisma } from "blitz"
import { PrismaClient } from "@prisma/client"
// const EnhancedPrisma = enhancePrisma(PrismaClient)
export * from "@prisma/client"
export default new PrismaClient()and it seems to vastly improve TS perf.
fleck
commented
3 years ago ehh, on second thought maybe the perf improvement in blitz was a fluke... Definitely snappy in a fresh nextjs setup even after prolonged use, but it doesn't have nearly as many deps and source files as my blitz app.
flybayer
commented
3 years ago Hmm interesting. New thing for y'all to try. Install blitz@canary and typescript@4.4 (just released today). Then delete .blitz
Extra-Extra-Dev
commented
3 years ago @Extra-Extra-Dev Since I've started using blitz vscode intellisense has always been slow, no matter what version of TS I'm using. How many lines is your generated node_modules/.prisma/client/index.d.ts file? Mine comes in at a hefty 33505 lines....
I'm too embarrassed to say.:| 124792
Call me "the canary in the coal mine". It seems I just love being the probe in to problems ahahahha.
Actually @flybayer .. This is very much how I've been/was "prodding" Blitz. I had been testing capabilities and way-of-working against a large schema (real world). Lots of files (early on) by running all the CRUD generation against that schema, then testing builds (remember my problems with builds early on(?) ) -- all this before actual code production and actual commitment to Blitz. It was less about development, and more about NOT being a lobster in hot water later. Thus my schema was big and flushed out first and early. But.. that said...
I will =>maintain<= that I still need to teardown and build up my schema and see if I have some problem ( maybe some recursion I'm not seeing (??) ) .. as I have more schema than code-written-to-consume/use it. But in the spirit of what I'm doing -- I've at the least found an edge case or a depth case of some form (or a newb problem to warn/help others with reporting a behavior and possible symptom). Is it recursion? I'd love to find a way to know via logging or outputs Looking at all 124k lines, I'm hard-pressed to find the recursion there at quick glance -- i'll need some coffee and fresh eyes!. Or maybe it's just the memory use or behavior of the specific versions. (cough, recursion(?) as @fleck said.) .. it could be turtle soup. So I need to audit this! (this weekend!?)
And I'll certainly try the new library version combo shortly and report back. But I've been coding right along and swiftly by holding back my versions so far. Was kinda waiting for this next 40.canary version(s) to formalize.
(sorry for the delay in response, @fleck)
dbrxnds
commented
3 years ago @Extra-Extra-Dev Since I've started using blitz vscode intellisense has always been slow, no matter what version of TS I'm using. How many lines is your generated node_modules/.prisma/client/index.d.ts file? Mine comes in at a hefty 33505 lines....
I'm too embarrassed to say.:| 124792
While trying to create a little proof of concept as an option for our new stack, I ran into this intellisense issue aswell. After generating the client, our node_modules/.prisma/client/index.d.ts file comes in at a whopping 1.151.445 lines.
Now, my schema was generated using introspection of our current database, which admittedly includes a lot of legacy tables that would no longer be used in the Blitz stack, however, I am not quite sure what would otherwise be the best way to go about this. Maybe manual mapping would be better but we would prefer to keep our entity "management" handled by our old stack, at least for now. Meaning we would also have to manually update tables in Prisma for every change we make.
Has anyone gotten further with this?
malekjaroslav
commented
3 years ago I have the same issue in WebStorm, it doesn't load the types at all 99% of the time. It's getting stuck somewhere in the enhancement method. I am on the latest canary version (9) and typescript 4.4.
Extra-Extra-Dev
commented
3 years ago Whoa! @iDavidB !!!! Now I don't feel so bad at 124792. But see now, @flybayer , @iDavidB just echoed my way of working. I've been/was prodding the full blitz stack early on. So, (MONTHS back) ignoring UI -- I started with DB first and flushed out the schema, en-masse CRUD generation, and building -- to see the full pipeline and where and how the whole thing behaves (and painfully and embarrassingly break while I learn). But authoring slowed me wayyyyyyyyyyyyyyyy down and be came uber uber frustrating which is why I chimed in on my WoW and schema.
As promised over the past weeks i've been cleaning up my schema as i've been diving deeper in to the project. I may or may not of cleaned it up. It's certainly better. Just as complex, more complex even, but less likely any recursion at this point -- and still slowness issues. I keep my Task Manager open and periodically just close the Extension Manger instance of VC Code and start all over again.
I'm still on the current versions stack as mentioned above. A bit too deep-in to upgrade at the moment as I'm onboarding a team. When we are out of this Canary build I'll do a full upgrade and report back. I also have a multi-platform team now -- some on WIN some on OSX -- so i'll have news there.
Cheers all.
LouGhys
commented
3 years ago Downgrading to "typescript": "4.2.4" was the improved for me.
jxe
commented
3 years ago I guess a workaround would be to put prisma and the queries & mutations fns in their own typescript project, linked with typescript project references, exporting an index.d.ts only for the query/mutation functions.
I guess this is kind of anti-blitz in nature. But has anyone tried it?
Extra-Extra-Dev
commented
3 years ago Although it's been reported here by @fleck and by others on Discord conversations (million line Prisma file scenario) that removing EnhancedPrisma was not great or did nothing - I must say I see improvement. I'd not tried this fix until yesterday. I apologize.
Before: Task Manager the memory usage WAS in the 1000MG range and using 60% of CPU when recalculating/generating autocomplete/intellisense. It did so every few minutes or minor or NO changes of a page -- making authoring -- nearly impossible and sucking up all CPU and making the experience... nasty.
Now: With removing EnhancedPrisma - I notice a much smaller footprint in the 500MB range initially and then the (what I assume is the autocomplete/intellisense recalculation) thread seems to keep only 100MB alive and uses a few CPU clicks now and again. Autocomplete is peppy. I can work.
I'm on TS4.4.3, Zod, 3.9.5, Blitz, 0.41.
Gonna keep holding on. Maybe something will be found as time goes on. I need to revisit everything I lose without authoring with EnhancedPrisma. Certain, it seems, I could deploy with it to gain it's benefits. What is it thats making it so upset every 2 minutes and hogging memory. Who/what's triggering this heavy-scan when nothings changed? What's being rescanned? schema? or files? or both? (just thinking aloud. maybe i'm helping.)
Anyways.. happy for today .. until I found out I've shot myself in the foot.
malekjaroslav
commented
3 years ago @Extra-Extra-Dev I didn't remove enhancePrisma, I just explicitly typed the client with as PrismaClient & { $reset: () => any} and that helped as well
Extra-Extra-Dev
commented
3 years ago @Extra-Extra-Dev I didn't remove
enhancePrisma, I just explicitly typed the client withas PrismaClient & { $reset: () => any}and that helped as well
No change/improvement with this suggestion.
malekjaroslav
commented
3 years ago @Extra-Extra-Dev I didn't remove
enhancePrisma, I just explicitly typed the client withas PrismaClient & { $reset: () => any}and that helped as wellNo change/improvement with this suggestion.
import { enhancePrisma } from "blitz"
import { PrismaClient } from "@prisma/client"
const EnhancedPrisma = enhancePrisma(PrismaClient)
export * from "@prisma/client"
const client: PrismaClient & { $reset: () => any } = new EnhancedPrisma()
export default clientDid you do it like this?
jxe
commented
3 years ago Upgrading to typescript 4.5 fixed this for me. Apparently they broke an optimization and then fixed it again.
malekjaroslav
commented
3 years ago I can confirm, TS 4.5.1-rc works like a charm
Extra-Extra-Dev
commented
3 years ago I can confirm, TS 4.5.1-rc works like a charm
@jxe @malekjaroslav . ..going to research/implement now.
BTW @malekjaroslav I will say your latest full-code example does seem to have a benefit with quick-testing. (Thats some funky code voodoo buddy! I understand it at surface.. and I wonder if Flybear will want to adopt it) I've been trying to wait to collect more evidence over time, but at first-glance it was testing well with less loss-of-control spikes. I wont say that it's benefit is confirmed yet, though, but 'marginally yes'. I see CPU spikes, but without loss of control with your code example.
Either way, . . .based on this dual-post on TS4.5.1 I'll quickly move to that and A/B & C/D test ..... with the changes from @malkomalko.
Nice one guys. ... .BRB....
Extra-Extra-Dev
commented
3 years ago @jxe @malekjaroslav
Well I'm gonna say TS4.5.1-RC is an improvement. I tested without @malekjaroslav's suggestions and feel/see improvement that is considerable. There are occasional small, sluggish lags -- but survivable. @iDavidB ... I think many of us would be curious for you to try this.
I also tested/tried TS4.5.1-RC with @malekjaroslav's mod and feels even peppy peppy peppier. Of course I'm just kinda clicking around over time at this point trying to get feedback to you. But, two (2) magic bullets? Anyone else combine both? I assume Málek did.
Will be waiting with bated breath for comments from @flybayer.
flybayer
commented
3 years ago Good news for TS 4.5! And if the type code workaround for enhancePrisma does improve perf, then we can export a type that has any additions we add to make this cleaner. And switch to that by default.
What is the problem?
Ever since I updated blitz from v0.33.0 to v0.37.0 I've noticed a huge delay in retrieving type definitions and autocomplete when using vscode.
Paste all your error logs here:
Paste all relevant code snippets here:
V0.37.0 Dependencies
V0.37.0 .eslintrc.js
Version v0.33.0 Dependencies
V0.33.0 .eslintrc.js
What are detailed steps to reproduce this?
Run
blitz -vand paste the output here:Please include below any other applicable logs and screenshots that show your problem:
No response