language-tools: VSCode Prisma extension host crashing and interfering with editor usage

@janpio I would have not thought so myself, but file watching is apparently a very difficult problem.

Could you please try using vscode’s built-in file watcher? On Windows we are shipping a separate .exe that is written in C# and does file watching to isolate the high CPU usage. On other platforms we also depend on chokidar, but we still execute it on a separate process so we are isolated from crashes.

The fix is now in the latest 4.4.0 version on the marketplace https://marketplace.visualstudio.com/items?itemName=Prisma.prisma 🎊

For those who disabled the File Watcher functionality, you can enable it again.

Same issue as others, across two different machines.

What is the status of this, I don’t see it on the project board? The extension is unusable for me on windows, as soon as VSCode starts I receive multiple WARN UNRESPONSIVE extension host, 'Prisma.prisma' took ... logs.

Is there a temporary workaround where the offending feature can be have a vscode setting so it can be disabled. My primary concern is editing the schema.prisma file and getting the syntax highlighting, formatting and IntelliSense.

I do not have a good answer to the fact that VSCode decides to ignore changes in node_modules. We do that to protect against flood of file events, but it is arguably not a good solution, rather a pragmatic one. As it stands today, an extension cannot overrule this decision, even when explicitly asking to watch a path inside a watcher excluded folder.

Related issues:

• https://github.com/microsoft/vscode/issues/3025
• https://github.com/microsoft/vscode/issues/126809

@alexdima Thank’s for the comment!

However, we did use vscode’s built-in file watcher at some point, but this lead to errors that forced us to switch to chokidar.

TLDR: We need to watch a file that is located inside the node_modules folder. In order to detect changes to this file, we had to change the workspace settings (specifically ‘files.watcherExclude’), otherwise changes to node_modules were ignored by default at least for vscode’s buillt-in file watcher (chokidar does not care about this setting). This unfortunately lead to the creation of the .vscode/settings.json file every time you opened up a Prisma workspace.

Do you have an idea to solve this somehow?

Additional note based on further reading above: I use the Pretter plug-in on almost every save as well, I use ts-node, and I use nodemon.

Could be a connection to one or more, though nodemon is also going to be file-watching, so seems possible there’s a connection there?

Verified: After bisect, Prisma was identified as the problem. Note I’m running Insiders, but I’m really only running Insiders because the normal VS Code was crashing so much that I thought running Insiders might fix things, but no, the problem is the same in both.

Here’s the issue it wanted to file:

Issue Type: Bug

There are no reliable steps I’ve been able to isolate.

In general:

• Using a lot of TypeScript features (auto-complete, jump to definition, etc.)
• Running the debugger (especially multiple times; the first time often works)
• Running a task, especially one that uses nodemon to keep it up to date

Extension version: 2.25.0 VS Code version: Code - Insiders 1.58.0-insider (bfac07cd0e374c433c2c06d6999dabf9cf9d5d29, 2021-06-28T05:14:44.463Z) OS version: Windows_NT x64 10.0.19042 Restricted Mode: No

System Info

Item	Value
CPUs	AMD Ryzen 7 3800XT 8-Core Processor (16 x 3893)
GPU Status	2d_canvas: enabled gpu_compositing: enabled multiple_raster_threads: enabled_on oop_rasterization: enabled opengl: enabled_on rasterization: enabled skia_renderer: enabled_on video_decode: enabled vulkan: disabled_off webgl: enabled webgl2: enabled
Load (avg)	undefined
Memory (System)	31.95GB (12.94GB free)
Process Argv	–crash-reporter-id 1ea1d622-9637-463a-91c3-3a0788249eae
Screen Reader	no
VM	0%

I’m editing my typescript files. Also i has enabled prettier plugin in my VSCode. And when i save the file, then i get my editor be little bit stacked frozen. It means my typings disapearing, my nodemon also not detect changes intil saving of file is done.

That means by editor cannot save the file before prisma language extension not done with their things.

Also while file is saving, my typings not working. But i can keep edit the file.

So, it’s happening not always. I has rate about couple times in 5 minutes.

Yes, i’m using ts-node-dev, nodemon for my dev. So, monitoring is always enabled.

So, the total:

1. Enabled prettier, prisma.
2. Using nodemon and ~same stuff
3. My VSCode stucking on saving file. Not crashing at all.

I just noticed i has the same warning or error as issue author, os i comed to here.

I really want’s to still using prisma vscode extensions, because it’s awesome.

Hi! @tjreigh @dslatkin @TheUnlocked @bombillazo @IRediTOTO @dariusj18 @TimMensch @SteveWallace @bpasero @alexdima @Satont @camero2734 @JonathanEkberg

I created a PR to fix the file watcher issue, I’m happy to report that on my computer (macOS m1) it’s now fixed. (CPU goes from ~100% previously to 0%)

Could you confirm it’s also fixed for you as well?

Follow these instructions

First, confirm that the CPU usage is high using the Prisma extension from the VS Code marketplace

• Open your project using Prisma
• If you disabled the Prisma File Watcher functionality, enable it again from the command palette:
• Open the schema.prisma file from your project
• Use “Open Process Explorer” from VS Code’ menu or open the OS Activity monitor
• Note / screenshot the CPU usage for the extension host above the Prisma extension process for the explorer or for the Activity Monitor, the Code Helper (Renderer) value and share it at the end

Second, confirm that with the new extension the CPU usage is low using a special build from my PR

Note: only the file watcher logic was changed.

• Uninstall any Prisma extension installed (uninstall is preferred as only disabling might interfere in some ways)
• Download https://github.com/prisma/language-tools/blob/artifacts/pull-request-artifacts/pr1243-prisma.vsix?raw=true
• Click “Install from VSIX” from this button (screenshot) or command palette and select the pr1243-prisma.vsix file
• Restart the VS Code application
• Open the schema.prisma file from your project
• Use “Open Process Explorer” from VS Code’ menu or open the OS Activity monitor
• Note / screenshot the CPU usage for the extension host above the Prisma extension process for the explorer or for the Activity Monitor, the Code Helper (Renderer) value and share it at the end

Third, if you have a TypeScript project, confirm that the file watcher works and that the types are refreshed

• Open a TypeScript file from your project where you have Prisma Client queries like await prisma.user.findMany()
• Open the schema.prisma file from your project
• Both should have no errors
• Edit the schema.prisma file and delete all the models (only keep the datasource & generator blocks)
• Run npx prisma generate
• In your TypeScript file, you should now instantly see a Type Error that should look like the following
• Undo the changes in your schema.prisma
• Run npx prisma generate
• The Type Error(s) in the TypeScript file should be gone now

Please share something like the following: I tested on … (macOS m1, Windows, Linux…)

1. Current extension: screenshot showing ~91% CPU (Note: CPU is only reported on the aggregated top line for some reason)
2. Using pr1243-prisma.vsix, screenshot after showing ~0% CPU usage 🎊
3. The typings were updated successfully after npx prisma generate, a Type Error was visible ✅

Thank you in advance 💚 Note: I’m waiting for some feedback before we switch to this new low CPU file watcher in a stable release on VS Code marketplace.

Having the same issue on Windows 10. Currently using VSCode without the extension and doing normal work, then VSCode Insiders with prisma extension installed to edit .prisma files.

Thinking outside of the box a bit.

The file node_modules/.prisma/client/index.d.ts only changes on prisma generate, right?

So what you need to do, technically, is to restart the TypeScript server when generate happens. So any mechanism to communicate that change should work.

Possible options:

• Send a message on generate to a socket that the Prisma extension is listening to.
• Touch a file that isn’t in node_modules and watch that one instead.
• It’s just one file. Poll its modification time every second or so. Polling a single file should take milliseconds at most. You could probably poll ten times per second with a tiny CPU overhead.
• On Windows only create a named pipe that can tell the extension when to restart TypeScript. (Or use one of the many named pipe npm packages that use Linux domain sockets on Linux).

Chokidar is a giant backhoe when all you need is a chisel.