Support for Chrome DevTools' new feature: Automatic Workspace folders

[bmeurer]

On the Chrome DevTools side we've been working on a new feature called Automatic Workspace folders, which improves the ergonomics and discoverability of the Workspace feature.

The feature basically allows the devserver to communicate information to the Chrome DevTools via a devtools.json file, currently limited to workspace folder (and a UUID for security reasons).

We have a proof-of-concept vite plugin at bmeurer/vite-plugin-devtools-json and support for this in ToT angular-cli (PR).

@patak-dev and @sapphi-red (and potentially others): We'd like to hear your thoughts whether it would make sense to put this directly into vite instead of asking developers to install a third party plugin or rely on meta frameworks like Angular and Next.js to set this up for them?

I'm happy to send a PR that basically merges the core logic from the plugin (it's really just the /.well-known/appspecific/com.chrome.devtools.json handling and the caching of the UUID).

cc @natorion

References:

• DevTools Project Settings (devtools.json) design document
• Automatic Workspace folders feature documentation

[patak-dev]

Thanks for creating the plugin and reaching out @bmeurer! Personally, I think we should have this in vite core directly. Let me forward this discussion to the rest of the team to see what others think.

[bluwy]

Is this planned to only be a Chrome-specific feature? Are there plans to also support more information in devtools.json?

I think I'd prefer in a separate plugin if that's the case so Vite is agnostic of browser support, and it'll be easier for y'all to add new features or change the API in the Vite plugin as it's in your control. Plus the possibility to abstract the logic for other bundlers as well if it's in a central repository.

[bmeurer]

Is this planned to only be a Chrome-specific feature?

It's Chrome-specific currently (but other Chromium based browsers could easily use it as well). Non-Chromium browser developer tools don't have a Workspace-like feature.

Are there plans to also support more information in devtools.json?

It's designed to be extensible, although at this point the only other bit of information that we might want to store in there is the URL where the site is deployed (see the example in the design doc), so that we can automatically retrieve the correct information from CrUX for local performance investigations (this URL could simply default to the url field from the package.json, but would need to be configurable beyond that). But nothing concrete here currently.

I think it'd be an advantage if this feature "just worked" out of the box for simple cases, by having it built into vite directly. For more sophisticated configuration, it could be done via a plugin, which overrides the default behavior in vite?

[bluwy]

If there's a possibility that the JSON is extended with information that Vite can't infer without accepting options, I'm not sure if we'd be ready to accept the additional customization as we usually want to keep the options low.

If eventually an external plugin is needed for the more sophisticated configuration, IMO it defeats the purpose of being builtin and adds maintenance to both ends.

But that's just my 2c on this. I personally feel like we shouldn't add browser-specific support, but maybe others feel fine of this change. At least I think the devtools.json feature should be stabilized and documented before we commit to making it builtin so we have a point of reference to maintain it.

[dominikg]

just dumping some thoughts here:

• as long as this is not an agreed upon standard, i prefer this to be in userland
• is adding protections in chrome that the well-known can only be accessed from local enough or would this create a leak in other browsers that don't have the same protection
• allowing direct source code modification can lead to transform errors that lead to vite error overlays or even full page reloads. a "try/catch" around the modification and only applying it on disk if it works would be important to preserve in-browser dx. I talked about this a while ago https://youtu.be/pJcbZr5VlV4?t=11412
• I really like the idea of browsers, ides and devservers collaborating to create a more "immersive" developer experience, however editing in the browser debugger pane is a very limited tool in that set. It would be most useful to quickly fix obvious errors encountered during step-debugging ala "oh ffs, that === must be !== instead". And thats possible today already if you connect your ide with remote debugger.
• For this to enable new ways to tackle DX, i think a deeper integration would be great, eg a browser devtools extension and a corresponding vite plugin creating a communication channel via the existing devserver websocket and establishing a common set of commands to go back and forth between the devserver and the browser (but this comes with security considerations too)

[dominikg]

regarding uuid and vite cache. If you need that id to be stable, it would have to be stored elsewhere, node_modules/.vite is regularly deleted by users or during vite dev --force.

Another option could be to use a hash of a path, similar to debug-id.