[Webkit-unassigned] [Bug 110493] New: Web Inspector: Segment built files by module boundaries as alternative to sourceURL

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=110493

           Summary: Web Inspector: Segment built files by module
                    boundaries as alternative to sourceURL
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: All
        OS/Version: All
            Status: UNCONFIRMED
          Severity: Enhancement
          Priority: P2
         Component: Web Inspector
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: jrburke at gmail.com
                CC: keishi at webkit.org, pmuellr at yahoo.com,
                    pfeldman at chromium.org, yurys at chromium.org,
                    apavlov at chromium.org, loislo at chromium.org,
                    vsevik at chromium.org,
                    web-inspector-bugs at googlegroups.com


It is common for performance to combine multiple files into one file. However those combined files are hard to debug. One mechanism to do so is to use //@ sourceURL, but this requires the combined code to be stringified and then evaled.

This can be awkward to use because:

* Some Content Security Policy (CSP) uses forbid eval. This is comes up directly for certain types of Web Apps.
* It causes an awkward interaction with source maps, makes it harder to get minified code.

With the coming use of modules in ECMAScript, and the use of AMD modules today, it is possible to use those module boundaries instead. This has a few benefits:

* No eval in play.
* as ES modules get adopted, there will be modules that are made up of tinier, scoped interior modules. Being able to report to the library author the module ID that had the problem will give better targeting of issues.
* //@ sourceURL relies on a path. With modules that use module IDs, paths become less important, and in some cases confusing in the case of bundled modules distributed and used in other projects: those paths will likely not match the application paths.

While ES modules are not done yet, they seem to have settled on using string IDs, like AMD and CommonJS/node use. In the ES case, a file containing many modules will have boundaries like this:

module 'some/thing' {
  // module code in here
}

For AMD, it looks like this:

define('some/thing', [optional array], function () {
  // module code in here
});

The developer tool debugger could look for these boundaries then use the module ID in the list of scripts ("some/thing" in the above example). Error line numbers would be reported relative to the module wrapper, with the first line number being the first line inside the module wrapper.

While ES modules are not complete yet, this can be put into use today, and work out any wrinkles by targeting AMD modules, as they are in widespread use.

I will likely need some pointers, but I am willing to write test cases if it helps.

(Also filed for Firefox at: https://bugzilla.mozilla.org/show_bug.cgi?id=843720

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.