Can't link CSS files to local versions in new workspaces system
Reported by
spen...@fieldbookapp.com,
Dec 12 2017
|
||||
Issue descriptionDevTools failed to link network resource to filesystem. Platform: Mac Chrome version: 63.0.3239.84 (identical behavior on Beta 63.0.3239.90 and Canary 65.0.3292.0) What are the details of your project? - Build System: grunt/stylus - HTTP server: express Assets failed to link (or incorrectly linked): Any css file in the project My typical workflow is to map the generated CSS files to the local filesystem, which allows me to make my changes in the stylus file, and see live updates shortly after, once it rebuilds. This worked well with the old workspace system, and saves a huge amount of time, since I don't have to constantly refresh the page, then navigate back to the point in our app that I'm working on. Now it looks like the mappings are supposed to be created automatically, but it's not happening. I'm also getting prompted to create the mappings with what looks like the old flow, but when I select app.css from the dropdown, absolutely nothing happens. Stuff I've tried: - Restarting Chrome and my machine - Switching to Chrome Canary and Chrome Beta. - Downgrading to an older copy of Chrome (v60). This works, since it's using the old version of workspaces. - Deleting all workspaces and adding them anew - Disabling all extensions (and clearing all workspaces to start from scratch) - Creating a new /etc/hosts entry (trying to get a clean slate in the hopes that something was just in a weird state for localhost:5000) - Creating a dummy directory structure using symlinks to more closely match the web server paths There's another rough mirror of this directory structure, which is generated at runtime by nap. Not reliably, but I can sometimes jiggle Chrome into mapping to those files. Unfortunately, this is useless, since those files are generated lazily by the server, and not by the build system, so they don't update live. To be clear, I have the same issue regardless of whether this other asset directory is included in the workspace. It also looks like the UI copy is outdated? The prompt says "Use context menu to establish the mapping at any time". But there appears to be no such context menu item anymore. Similarly, the prompt links to https://developers.google.com/web/tools/setup/setup-workflow for more information, which appears to document the old workspaces.
,
Dec 12 2017
,
Dec 12 2017
Some more information; I finally jiggled it into working partially. I have no idea which parts of this process are necessary, and I'm a bit reluctant to touch anything now that it's usable. But here's what I did (I think): 1. Cleared out all my workspace folders, then added the entire project directory to workspace 2. Downgraded to Chrome 60 3. Set up the mapping in 60 4. Upgraded back to 63 So now it's _sort of_ working. The caveat is that if I reload, I lose the link. To restore it, I have to create a brand new tab, load the page, and _then_ open the dev tools after the page has loaded. Then it will work, and I'll get live updates up until I need to refresh again, at which point I can repeat the new tab process.
,
Dec 20 2017
,
Dec 8
Workspaces 2.0 is imperfect and there's no feasible way to make it work for everybody. Archiving since we currently don't have resources to allocate towards improving Workspaces story. |
||||
►
Sign in to add a comment |
||||
Comment 1 by spen...@fieldbookapp.com
, Dec 12 2017A couple more things I thought to try, to no avail: - Add the entire project directory. Links all of my sourcemapped JS files just fine, and (this time) mapped the CSS files to ones in the /assets/ directory created by nap (which as I mentioned, doesn't help me) - The above, but right-clicking the assets directory and choosing "Exclude folder". Didn't seem to do anything at all ("assets" still showed up in the Filesystem tab) - The above, but adding /assets/ to the exclude regex in the DevTools settings. That did filter out the assets folder, but my files still don't link. - Check that the CSS files I'm trying to link are absolutely identical. They are. (Not sure if that even matters)