New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WhatWG Loader Spec Blocking Issues #381

Closed
guybedford opened this Issue May 24, 2015 · 8 comments

Comments

Projects
None yet
3 participants
@guybedford
Copy link
Member

guybedford commented May 24, 2015

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 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/whatwg/loader/issues/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

This comment has been minimized.

Copy link
Contributor

probins commented Jun 10, 2015

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

@guybedford

This comment has been minimized.

Copy link
Member

guybedford commented Jun 10, 2015

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.

@guybedford guybedford changed the title New spec release spec clarifications WhatWG Loader Spec Blocking Issues Jul 24, 2015

@caridy

This comment has been minimized.

Copy link
Contributor

caridy commented Aug 5, 2015

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

This comment has been minimized.

Copy link
Contributor

probins commented Jan 7, 2016

@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

This comment has been minimized.

Copy link
Member

guybedford commented Jan 7, 2016

@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

This comment has been minimized.

Copy link
Contributor

probins commented Jan 7, 2016

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

This comment has been minimized.

Copy link
Member

guybedford commented Jan 7, 2016

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

This comment has been minimized.

Copy link
Contributor

probins commented Jan 20, 2016

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment