Allow tooling to provide local file paths to be used in Sources panel
Reported by
d...@davejeffery.com,
Nov 11 2016
|
||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2916.0 Safari/537.36 Steps to reproduce the problem: This is a feature request. The goal is to provide syntax to map a URL resource back to it's corresponding file on local disk. This could provide hinting to the Sources panel in DevTools and allow local sources to be added to workspace and mapped without any manual configuration by the user (they would only need to accept the permissions dialog). What is the expected behavior? The existing syntax for linking a source file to it's map could be used (i.e.. `//# sourceMappingURL=...`). A possible name could be 'localFilePath': ```js //# localFilePath=/Users/Dave/Sites/MySite/scripts/foo.js ``` ```css /*# localFilePath=/Users/Dave/Sites/MySite/styles/main.css */ ``` ```html <!--# localFilePath=/Users/Dave/Sites/MySite/styles/index.html --> ``` If following the sourcemap syntax then I guess it also makes sense to allow mappings using HTTP headers instead of comments also. This could also be used alongside sourcemaps: ```js //# localFilePath=/Users/Dave/Sites/MySite/scripts/foo.js //# sourceMappingURL=/scripts/foo.js.map ``` What went wrong? This is a feature request. It would be usefule for third-party build tools and local dev servers. Did this work before? No Chrome version: 56.0.2916.0 Channel: canary OS Version: OS X 10.12.0 Flash Version: Shockwave Flash 24.0 r0
,
Nov 15 2016
Hi Dave, We try to solve this problem already - checkout the "Persistence2.0" experiment in Chrome Canary which figures out resource mappings automatically. Let me know how it works for you
,
Nov 15 2016
Thanks. I just tried out the experiment and it seems to work well. I think this will be a nice UX improvement for those already using workspaces. This is only half the problem though, as it doesn't improve workspace discoverability/hinting. Whenever I show workspaces to other devs they generally think it's awesome, but most of them didn't know that it existed despite spending a lot of their time in devtools already. My suggestion is that third-party tooling (webpack etc..) could provide hinting to the Devtools. This could allow Devtools to prompt the user that a workspace is available for this site and provide a much nicer one-click 'on-boarding' experience.
,
Nov 17 2016
Yes, the discoverability is poor. I believe we can improve drastically on the devtools side first - there's a lot to be done which doesn't require any new standards. We'll focus on it as we polish the implementation, ideas are welcome! While we're here - if you have any issues with the automapping algorithm in the "Persitence 2.0", please, let us know. We want to eventually make it a default.
,
Nov 17 2016
Yeah, I've tried Persistence 2.0 with a couple of projects and it seems to just work, I haven't encountered any issues yet. Off topic but I did notice though that the 'Live Sass' experiment seems to no longer be working. Is this a known issue?
,
Nov 18 2016
That's not a known issue, thank you for the heads-up! created a bug report: crbug.com/666946 As per the persistence2.0, do you have any webpack projects? Automapping might have issues with webpack due to its thick runtime.
,
Nov 19 2016
No, I'm working on a Webpack project in Electron but not in the browser. Electron is usually based off Chrome Stable so I'm guessing the experiment isn't available there.
,
Dec 2 2016
Closing this issue for now since it seems to be covered with the "Persistence2.0" experiment.
,
Dec 2 2016
|
||
►
Sign in to add a comment |
||
Comment 1 by kozyatinskiy@chromium.org
, Nov 12 2016Status: Assigned (was: Unconfirmed)