Perhaps explain the other available shortcuts too:

Cmd+/
Opt+Delete

Also, something I've noticed since I almost exclusively use workspaces now. When I have a file open, say main.js. If i have a breakpoint on a line that is hit when I hover over something, there's another instance of main.js that opens up, which if I try to make changes in and save, it's not actually saving. I have to switch back to the other main.js file I was editing and make the change there. I'm not sure what's up with that. Probably has something to do with what VM is. Although, sometimes a file has VM next to it and sometimes it doesn't. Curious about this.

I've experienced this same thing. It seems like the mapping is not 100% perfectly matched in some cases (when recompiling and dynamically swapping the function contents?

I've made what @jaredwilli mentions happen by adding a breakpoint, breaking on it, altering code, and then saving and kicking off the auto-recompilation. A new editor tab opens and it has a [VM] tag in the title.

@SchizoDuckie hah thanks for coming around these parts! :)

that's a good bug report. I'll speak to our workspaces engineers to look into it.

Suggestions:

• Features: add folder, refresh, create new file, delete, ignore lists.
• Document scenarios where it makes sense to author an app directly inside of DevTools Workspaces vs where it doesn't. Currently not really talked about anywhere.
• If linking/embedding video, verify that the features shown/UI haven't massively changed. If they have it may be worth adding a note.
• Link to DevTools Terminal article? discusses a workflow using Workspaces + terminal extension

@dr4b here's my ideas for how to best cover the feature

• Why workspaces? Because copy pasting your final changes back into another editor is slow. And more benefits come when we merge the the editor with the devtools.
• What having a mapped workspace is like. What development feels like and why everything is instant and persisted (styles pane, sources (css & JS, html) and augmenting new files etc)
• Concede that you may have editor familiarity or editor features you can't give up for 100% of the time. point to the remote debugging clients examples page.
  • Devtools doesnt need to be your primary editor to use workspaces. But it will likely make sense to use as your editor during a step debugging session or iterating quickly via Live JS recompilation
• How to use it
  • dev server only. not really usable for production files your filesystem can't change. works for file:/// but you'll need to do the adding work anyway
  • add the workspace. MAP IT. always map it, imo.
  • persistence. it all works
  • ignoring files. managing files (add/create/delete)
  • cmd-o and search all files
• If you change a file but dont hit save, (or if you change a JS file that's not mapped), you may see a [vm] file that looks very similar come up. That is the version of the file that the JS engine is processing. Until you hit Save workspaces will not merge the two.. so do that.
• Live JS Recompilation (née liveedit)
  • what it means
  • it doesnt work for everything, but function redefinitions are its break and butter. also you dont get visual feedback if it totally worked or not, so... be understanding :)
  • a dirty buffer gets you a * in the tab bar. hitting save (cmd-s) does two things:
    1. patches it to the JS engine for recompilation
    2. saves it to disk if you've set up a workspace. if you havent' set up a workspace, the background may change colors to indicate the change wasn't persisted but it was however sent to v8.
  • You can always right click and save any file in Sources to save to disk, but it's a file-by-file operation. Workspaces allows you to do this for an entire project folder, which is probably what you meant.
• Workspaces with CSS Preprocessor support
  • we have css sourcemaps which means you can map from styles pane CSS back into what you wrote as sass/less/etc
  • now when you map it back you can change it and save to disk via workspaces
  • of course you'll have to have a daemon on --watch that recompiles for you, but devtools will pick back up the new .css files and update them.
  • we should have a video for this. i'll do it.

Doing more

• devtools terminal
• other things that augment the "devtools as an editor" workflow.
• how a mapped workspace is actually great while using an external editor. basically like Emmet LiveStyle but just on every devtools focus it brings in the new version of your file. See internal email from John J Barton talking about the Editor->Workspaces->recompilation flow. Also works great for CSS.

caveats:

• can't go from DOM back into HTML. you probably wouldnt want to. but editing the HTML file is easy..

http://remysharp.com/2013/07/18/my-workflow-v3-full-coding-stack/ video shows an unmapped workspace and how you can edit backend files easily. In the comments i point out the advantages to mapped workspace.

http://gregrickaby.com/turn-chrome-developer-tools-into-an-ide/ this kinda shows what the story is for workspaces in the larger scheme of things.

Initial docs published: https://developers.google.com/chrome-developer-tools/docs/workspaces

This all sounds wonderful, but are pure HTML files still used in contemporary web development? In these times of Dru pals, PHPs and Node.js, I can't imagine how many use cases there are for having static HTML pages. Or is this feature solely intended for editing client-side script and css?

Already a good document. In my opinion the "Refresh" section should give more details what happens and when, when files get changed outside of Chrome. What's really unexpected is that only the file of the open tab (sources view, not browser tab) gets recompiled. When I change more files I must visit each tab in dev tools to recompile them. Is it possible to recompile all changed files at once, not only the file of current tab?

@PavelMaximov Sounds like something to bring up on the Issue tracker for the project. This is just a documentation repository.

I'm trying to understand how the mapping from network source to local file system works. As soon as I right-click to map a single network source to a local file, it tells me I should reload. When I do, the source for the webserver disappears forever (presumably because it has been mapped). That implies that chrome figures out some kind of relative mapping between two files, and applies that mapping to all files. Is that correct?

However, there are a lot of cases where the server's hierarchy of resources does not match the file system's; in my case for example, /style is served by a node server from a different filesystem location than other parts. Hence, it looks like the styles pane cannot show me the source file name anymore for something I'm inspecting.

Is there a way around this, or am I supposed to make sure the filesystem hierarchy completely matches the server's?

The normal scenario works for me, but what about the scenario where I am editing a remote file and don't have the remote file on my local disk? I expect to be able to map any arbitrary url to a local file.

For example:

• Imagine I am loading jQuery from "http://somecdn.com/jquery.js".
• I create a file "C:\myjquery.js" and put my own Javascript in there.
• Now when the page requests "http://somecdn.com/jquery.js" I want to load "C:\myjquery.js" instead

This does not work. Instead I get this error:

Workspace mapping mismatch

The content of this file on the file system: [path]
does not match the loaded script: [path]

@breck7 That is the exact thing issue #151 is open for documenting. Currently what you want to do isn't possible with the DevTools. Additional extensions are required.

In the other issue is a link to a bug report. You can star that issue to let the developers know you are also interested in the feature addition. Please do remember to not comment with simply +1 or other noise. Stars are sufficient to get things prioritized.

Done! Thanks @Garbee!

@eslachance I don't think there are any current plans for the team to add the functionality. Best thing to do is submit a feature request on the issue tracker against DevTools and see what they say.

In the documentation I see edits made in the elements panel should persist and save immediately. I'm unable to create this behaviour though, and instead have to edit the relevant file under "sources" and save it. Is there still away to persist changes made in the elements tab? (otherwise you lose the ability to see immediate changes).

Thanks for the quick reply Paul, If I understand correctly my work space is mapped as I can control click on a property in the elements tab, to be taken the sources tab, and the relevant LESS file / line. When I save the changes they are saved to disk locally. I just can't get it to work in the "elements" tab where I can actually see live changes.

@paulirish I have the same issue as @TristanBrotherton - is there any way to debug this? As Tristan says, workspace is mapped, and edits to the sources panel persist to the file system correctly. The only missing thing is that changes in the elements panel do not sync or persist to the source panel in any way (nor the reverse. Sources/Elements are out of sync).

cc @aslushnikov

@JohnONolan @TristanBrotherton hi guys, I've an idea of what might be happening, but at first lets see if I understand your scenarios correctly:

1. You author your styles in LESS
2. You transpile LESS files into CSS files with sourcemaps
3. In DevTools, you setup a workspace, which maps your CSS stylesheet to CSS filesystem files, and LESS sources from sourcemap to LESS files on the filesystem.
4. In elements panel, you see CSS styles. If you ctrl-click on the property, you're brought to the LESS file in the sources panel.

In this case editing styles through elements panel actually edits CSS - which is instant, but this doesn't change your LESS file. Whereas if you edit a LESS file in Sources panel, the editing is not instant.

@aslushnikov That sounds accurate. Sounds like its a workflow issue. My misunderstanding from reading the docs was that it would update the LESS file.

@aslushnikov Yes. In my case, PostCSS rather than LESS, but everything else is the same.

The main things I note are:

• Changes to the PostCSS/LESS file in the sources panel do write to the file system, but are not visible when switching to the elements panel.
• Changes to the elements panel instantly appear in the browser, but do not carry over to the sources panel or write to file.

Everything in the sources panel is working exactly right - no issues at all - it's just the elements panel which seems to be disconnected, somehow, from the sources.

As a point of reference, when the workspace is mapped to the compiled CSS file rather than the source PostCSS/LESS file, then the elements/sources panels are synced correctly and as expected.

Does this help at all?

Correct. Saving whole folders is not currently supported.

Does the situation changed after 2 years? Is it still not supported?

@Suncatcher Nope. There isn't an issue for it to be tracked and implemented by the team when they have time. This isn't a place the team looks for work. If someone wants that functionality they'll need to file a bug at the chromium bug tracker.

If someone wants that functionality they'll need to file a bug at the chromium bug tracker.

Okay, I fixed this horrible deficiency)

+1 i want this feature

+1
I want this feature

@Garbee
I think I did not explain understand, so please look images

Same problem, I think it will never be fixed.
Bug in bugtracker: https://bugs.chromium.org/p/chromium/issues/detail?id=596037