WhatWG Loader Spec Blocking Issues

[guybedford]

The release of the new specification work (on the 1.0 branch here), is pending the clarification of the following spec issues:

• Will there be a locate hook? See Why a locate hook is unnecessary whatwg/loader#52.
• Load metadata - is there still a metadata object passed as a last argument to hooks, or will implementations need to maintain a private store keyed by resolved name for this?
• Is the global loader called Reflect.loader? Looking like System.loader for the instance and Reflect.Loader for the class currently (http s://github.com/names for Loader constructor and default loader whatwg/loader#34#issuecomment-127701746).
• For extending the loader, do we extend Reflect.Loader or Reflect.loader.constructor? Reflect.Loader
• It is looking likely contextual loading will be via import.default and import.namespace. So will the top-level Reflect.loader.import function return a namespace only?
• Hook syntax - are hooks class methods, created via Reflect.loader.hook('normalize', normalize) or both? Instance methods set via the setter.
• Sites table - will wildcards be permitted like paths configurations (eg 'jquery/*' -> '/path/*')

Most importantly, with all the above, some idea of the stability and backwards compatibility of the spec is important to ensure we're aligning with user needs.

[probins]

what about mappings, as in whatwg/loader#20?

[guybedford]

Yes it would actually be good to confirm if there are or aren't wildcards in the sites table. Apart from that, it's a specified system. It does bring up another point - which is that we now need a certain level of guarantee over how stable and backwards-compatible the spec itself is, as we start to rely on it more.

[caridy]

inline

1. Is the global loader called Reflect.loader?

default loader instance will be under System.loader

1. For extending the loader, do we extend Reflect.Loader or Reflect.loader.constructor?

class myCustomLoader extends Reflect.Loader {}

1. It is looking likely contextual loading will be via import.default and import.namespace. So will the top-level Reflect.loader.import function return a namespace only?

Partially solved. System.loader will be available on every realm, which give you access to the default loader instance. Inside modules, you can access that, but you will also has access to the imperative import form, which bounds to the loader used to load the module in question, which is better... but that has to be defined.

1. Hook syntax - are hooks class methods, created via Reflect.loader.hook('normalize', normalize) or both?

hooks are instance methods, whether you set up hooks on the default loader instance (System.loader) or a custom loader instance, it is up to user.

[probins]

@guybedford - no hurry, of course, but if and when you have a moment I'd be interested to know how you see the current status. Item 1 on the list, for example, refers to issue 52, which is now closed. In more general terms, as the spec now has different milestones, I'm wondering whether having a 1.0 still makes sense, or whether it wouldn't be better to phase implementation to match those milestones.

[guybedford]

@probins I think we should get out a 0.20 (a nice round number), that implements the features of the loader spec as it is now. We should of course aim to separate things like the module reflection API, which can probably be added later, but the core implementation should be just the update of what we have here I think.

Getting the <script type="module"> support in parity with the spec would certainly be important too (although it mostly is already, it's the edge cases that need work!).

I don't think this project should "shink" too much though. If we just implemented the first step of the roadmap, that would be a step backwards here.

[probins]

If we just implemented the first step of the roadmap, that would be a step backwards

good point :-) So perhaps just continue in evolutionary mode, rather than aiming for one large 1.0. Even when the spec is finalised, it wouldn't surprise me at all if later changes are needed once people start implementing it in the real world.

<script type="module"> seems to be making progress at whatwg/html#443

[guybedford]

Exactly, rather get an ok 0.20.0 out sooner and then keep iterating than try to make it a big major release. We've almost got that branch running to spec anyway, so we should in theory be pretty close to that.

Yes the module tag is making some great progress.

Also contributions to help move this project forward would be incredibly welcome. It's been great to see the PRs from @joeldenning.

[probins]

I see Domenic has just merged module script into whatwg/html