feat(vite-devtools): automatic Chrome DevTools workspace mapping

[0xTaneja]

Description

closes #2803

Select what type of change this PR introduces:

1. Just code/docs improvement (no functional change).
2. Bug fix (non-breaking change which fixes an issue).
3. New feature (non-breaking change which adds functionality).
4. Breaking change (fix or feature that would cause existing functionality to not work as expected).

Update Waspc ChangeLog and version if needed

If you did a bug fix, new feature, or breaking change, that affects waspc, make sure you satisfy the following:

1. I updated ChangeLog.md with description of the change this PR introduces.
2. I bumped waspc version in waspc.cabal to reflect changes I introduced, with regards to the version of the latest wasp release, if the bump was needed.

Description

Added Chrome DevTools “Automatic Workspace” support to Wasp apps in dev-mode. here is how i implemented it ,

• I Introduced vite/devToolsJson.ts plugin that serves
  /.well-known/appspecific/com.chrome.devtools.json:

  {
    "workspace": {
      "root": "<project-root>",
      "uuid": "<cached-per-project-uuid>"
    }
  }

• wasp-cli launcher now injects WASP_PROJECT_ROOT; if its not present plugin falls back to walking up to the
  first directory containing .wasp/ for projects started directly with Vite.
• Cross-platform path normalisation (Windows, WSL \\wsl.localhost\<distro>\…, Docker Desktop).
• Per-project UUID generated with crypto.randomUUID(), persisted in
  node_modules/.vite/<hash>/uuid.json.

[cprecioso]

Thanks so much for the investigation and the implementation 🙏🙏🙏, I hope it wasn't too hard, and that it was fun too!

I have some minor style nitpicks, but I can bring those up later. First, I have two major questions, can you take a look?

[cprecioso]

I see this code is very similar to the one at https://github.com/ChromeDevTools/vite-plugin-devtools-json.

Are there any major changes? Can we use vite-plugin-devtools-json as a dependency directly? That code is MIT licensed, so if we copy it in, we should at least find a way to credit it. But it's easier to just use it as a dependency.

[0xTaneja]

yeah its similar , but we added findProjectRoot() which respects WASP_PROJECT_ROOT when present, otherwise walks up until it finds a .wasp folder, falling back to config.root. This is essential for monorepos and for the generated .wasp/out tree. another thing which i made is pathnormalization that rewrites Linux paths into UNC form so Chrome can mount them as a “file-system workspace” on Windows hosts – something the upstream plugin doesn’t try to solve. other than those points the file is still ~90 % identical to the MIT-licensed original plugin.

[0xTaneja]

@cprecioso if you say , i will use it as a dependency

[cprecioso]

Not super against this, but have you explored passing this data to the vite.config.ts template? I think that would be a cleaner design.

[0xTaneja]

@cprecioso yes i explored it but the thing is The absolute project path isn’t known until wasp start runs, and it changes across machines/CI/WSL. Hard-coding it into the generated vite.config.ts would go stale; exporting it at runtime with WASP_PROJECT_ROOT always gives the plugin the correct path.

[cprecioso]

@0xTaneja
Okay, I reviewed your answers, and I think there's a better course of action, if you're along for the ride! (If it gets too much, just say so and we can take it over)

---

I think the improvements you made to the plugin are super nice! Other users of the plugin will also probably want to have them. And we'd prefer to just use the plugin as a dependency if it's so similar. So this is what I would do:

1. Open a PR against https://github.com/ChromeDevTools/vite-plugin-devtools-json, with your improvements. Both the path normalization, and being able to set your custom root.

   They will probably not want to have any Wasp-specific environment variables in their code, that's normal! The root can be passed as an option to the plugin from the vite.config.ts.

2. Once they merge and release that, we can directly use the plugin as a dependency in our Vite config.

---

Moreover, I'd like to scrap the environment variable approach, it feels like a way too wide solution for the problem we have. I'd prefer to write that variable into the vite.config.ts template and passing it as an option to the plugin. wasp start will write the internal vite.config.ts every time it starts, so we don't need to worry about this data being outdated across machines. You can edit the vite config template here and the data passed to it here.

---

What do you think? Is this plan nice for you? You'll also get twice the open source contributions from this 🤘

[0xTaneja]

@cprecioso the plan sounds perfect !! let's tag team and win this !!

[0xTaneja]

okay i will start editing vite config template and data associated with it

[cprecioso]

oh @0xTaneja I meant to communicate that this is what you should do! this way the contirbutions are on your name!

[0xTaneja]

@cprecioso understood captain !! will be doing this !!

[cprecioso]

Linked to ChromeDevTools/vite-plugin-devtools-json#15

[0xTaneja]

@cprecioso, first part is done, pr got merged for chrome devtools, now i can focus on second part of directly using the plugin as a dependency in our Vite config,
maybe you can remove blocked label from this pr now.
and also i made a pr to #2956 so maybe you can review it if not yet done.