1248830 - Investigate loader for content / devtools.html

Status: RESOLVED DUPLICATE of bug 1291049

(DevTools :: General, enhancement)

Description

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

As we move closer to devtools.html, we'll need to ensure we have a solid plan for loading modules.  

In the initial stage of devtools.html, we may keep chrome privs and only do the XUL -> HTML transformation, so our existing loader system may work.  Eventually though, we'll want to move to content privs, and so we'll need a new plan.

Some options include:

* ES Modules (bug 568953) plus the Loader spec (http://whatwg.github.io/loader/)
  * Unlikely to be ready in time
* SystemJS
  * Loads all common module formats (CJS, AMD, ES) without any UMD wrapper goop
* Webpack / other compilation step

Comment 1

[Alexandre Poirot [:ochameau]]

Bug 1240072 looks appealing. We may be able to use that soon!
Even if it requires chrome, we wouldn't need Component.* and the custom chrome loaders.

Comment 3

[James Long (:jlongster)]

jonco told me on IRC that `script="module"` has landed for privileged code, which means we can start using the functionality from bug 1240072.

I looked into it today. I don't have a good feature to really test this out on, but I got something basic working: https://pbs.twimg.com/media/CirhlgZU4AAh__N.jpg:large Everything seemed to work in various tests that I did.

This is very promising, but unfortunately the Loader spec which has a lot of important things in it is not close to being finalized. Without a loader, each module is essentially a <script> tag in the eyes of the browser. That means we have no control over how modules are loaded, paths resolved, etc. This severely limits the usefulness of modules.

So far, in devtools we've avoided pulling modules from npm or loading CSS from modules. That means our module usage is pretty straight-forward, and we *might* be able to leverage this. But we're already moving towards solutions where we can do things like use npm and load CSS, so using the current ES6 module implementation would remove any possibility for us to do that. It feels like a big step back from webpack.

One possibility is to work with the JS team to implement custom extensions to modules to expose Loader-like functionality. They've already brought up that possibility, because they are aware that <script> module are of limited usefulness for "real" apps. It should not be hard to convert our toolchain from proprietary extensions to whatever the Loader spec ends up being.

Until then, I'm not convinced we should sacrifice the usefulness of something like webpack just to avoid a build step. If we start developing devtools as normal tabs, and even separately from the Firefox repo, which is something we're experimenting with, the "getting started" experience is already far better than working with privileged code in Firefox. Just `git clone`, and `npm start`; that's it.

But even if we use webpack, we can write ES6 modules with the intention of getting rid of webpack whenever our platform has enough functionality to be useful.

Lots of stuff to discuss here, clearly, but I wanted to dump my thoughts after looking into ES6 modules.

Comment 4

[Tom Tromey :tromey]

A couple of requirements for the content loader came up during de-chrome-ification:

* It needs to supply the same pseudo modules that builtin-modules.js supplies.
  At least "promise" is used nearly everywhere.

* Likewise it needs to supply the same globals that builtin-modules.js supplies.
  Since our approach has been to make these globals mirror globals available in
  content, this shouldn't be a major problem.

* It needs to make sure that the IIFE in event-emitter.js (maybe there are other spots
  like this, I didn't check) takes the "require" branch.

Comment 5

[Tom Tromey :tromey]

Also see bug 1287915.  There we'd like to be able to read a particular .css resource
as data, for further parsing.

webpack has this one: https://github.com/webpack/raw-loader

Comment 6

[Tom Tromey :tromey]

There's also a shim Services module in devtools/client/shared/shim/.
require("Services") in content should resolve to that file.
Perhaps we'll add other shim modules there as well; the idea being that
in the content case we can check there first.

Comment 7

[Tom Tromey :tromey]

Right now we have a "CSS" module, which in content should just resolve to CSS --
but maybe we should convert this to a global.

Comment 8

[Tom Tromey :tromey]

(In reply to Tom Tromey :tromey from comment #7)
> Right now we have a "CSS" module, which in content should just resolve to
> CSS --
> but maybe we should convert this to a global.

I filed this as bug 1292574

Comment 9

[Tom Tromey :tromey]

event-emitter.js and presumably other spots assume that dump() is available,
so either the loader has to make this available (seems simple) or we'll need
a new bug to fix this up.

Comment 10

[Tom Tromey :tromey]

All the work for this bug moved to bug 1291049.