Release new loader branch

[guybedford]

It's really important now to release the 1.0 branch so that this project can again match the loader spec more closely.

I think it would make sense to keep it as a minor patch - say 0.20, at least until the loader spec is stable.

Even if we're not fully spec compliant, having the spec API is obviously a much better thing than still being on the old API, and it's a shame the new loader branch has just sat there now for over a year.

If anyone is interested in working on this please get in touch. If we can release it tomorrow we should. I'd hate to be holding this work back.

[probins]

what still needs doing? This is presumably linked with #381. I agree that it's high time this project moved on from the old spec. Would it help if we created a milestone with the outstanding tasks listed with 'PR welcome' or some such?

[guybedford]

I don't think we're even linked to 381 at all here either, as this project can continue to make regular breaking changes due to its nature.

We're currently running on an older version of the loader spec, so we could update to the latest PRs made over the last year, or at least a set of them including things like ensuring the new globals are all correct.

Then the main thing secondly would be a Babel 6 upgrade / recent Traceur upgrade, and updating the docs.

[probins]

and an update to SystemJS :-)

It's a long time since I looked at the 1.0 branch but I have some time, so, if you like, I can look through the code and see what I think still needs doing. Probably won't have time for any meaningful testing, but if it's usable it could be released as alpha/beta. I can also see what state the docs are in.

[guybedford]

In due course SystemJS as well certainly, but I think we should get this update out independent to SystemJS, and SystemJS can upgrade when the timing makes sense.

If you're able to look into this that would be a huge help!! As I say the rough main things are probably checking the top-level global names, Babel / Traceur upgrades and the docs. I can certainly provide as much detailed feedback as is necessary too.

[probins]

checking the top-level global names

you're meaning here Reflect.Loader and System.loader? Are there any other globals?

[probins]

Babel / Traceur upgrades

the question to me is what we're doing with transpilers - as in discussion of #463.

[probins]

ok, have now looked through the code. The bad news is that there's quite a few functions (in lib/loader.js) that do not match the current spec. The good news is that they're well documented with 'TODO', and from my brief look at least some of them should require little change. However, I don't think this is something that can be implemented 'tomorrow'.

On the top-level globals, lib/wrapper-end.js exports Reflect.Loader, Reflect.Module, and Reflect.global (is this official?). The system loader however is being assigned directly to System, whereas it should be in System.loader. I can submit a PR to change this.

I notice a couple of other places where out-of-date functions are being used:

• declarative.js uses new Module() which I think should be new Reflect.Module()
• module-tag.js uses System.provide() - not sure what this should be

system.js is creating site, though this is not (yet) in the spec.

On module-tag.js, as implementations are starting to appear, I think there needs to be some way for this not to execute if natively supported; trouble is I have no idea how you check that :-(

I would move the URL polyfill into userland. This is only needed for IE, and IMHO it should be up to the app developer to decide whether they want to support IE or not.

[probins]

one other out-of-date function: system.js is using hook(), which is still in loader.js but is no longer in the spec. This should be changed to the appropriate hook function, resolve() etc.

[probins]

@guybedford here's what I propose doing:

• create a new branch based on 1.0; I'd suggest calling this 0.50 rather than 0.20 to make clear this is a breaking change
• tidy up the out-of-date functions listed above
• start not with the loader but with the docs:
  • change the target browsers to modern ones, all of which now support ES6, including Map and Promise, as well as URL() (Safari is lagging a bit atm on general ES6 support, but this will change with the next release, due I believe in September)
  • older browsers, such as IE, can be used providing any ES6 code is first transpiled to ES5, and polyfills for Map, Promise, and URL are loaded by the app before the ModuleLoader, for example, from cdn.polyfill.io
  • remove URL and Map polyfills from code
  • support for ES6 module format:
    • native support if available (not atm sure how you check for that)
    • on-the-fly transpilation using traceur/babel if no native support (not suitable for production) (this implies using a build supporting only import/export)
    • support for System.register available with SystemJS
  • no longer support for paths, but this is available with SystemJS
  • list api changes to loader:
    • System.import becomes System.loader.import (apps can supply alias to ease transition)
    • other changes really only needed by those with custom loaders
  • clarify that module 'names' are now URLs (the spec is vague on this subject, but URLs are all that script type="module" implementations will support)
• as a start on loader.js, rearrange the current code to correspond with the spec, removing obsolete functions, and creating empty functions if no code currently available

We'll have to see then what time I have available for filling in the empty functions.
The tests also need to be changed/brought up to date.

[guybedford]

This all sounds really great, it definitely sounds sensible to take a high-level docs focus first. I've included some feedback below.

create a new branch based on 1.0; I'd suggest calling this 0.50 rather than 0.20 to make clear this is a breaking change

Sure, I've created a 0.50 branch based on the 1.0 branch.

change the target browsers to modern ones, all of which now support ES6, including Map and Promise, as well as URL() (Safari is lagging a bit atm on general ES6 support, but this will change with the next release, due I believe in September)

Agreed!

no longer support for paths, but this is available with SystemJS

Yes happy to remove the sites implementation.

as a start on loader.js, rearrange the current code to correspond with the spec, removing obsolete functions, and creating empty functions if no code currently available

This code was exactly to the spec previously, so following spec commits since the date of the loader code may be one way of going about this upgrade. This is a tough job though, so I certainly understand if you don't have time for this. I think a documentation-first focus and getting the other code points you've mentioned right first makes sense here. If we have something that runs, updating this project to that as an alpha with a caveat that this is still being updated to the new spec would be a great start, as it means people can be testing out the module tag, or testing out the loader spec API and seeing how it fits together, which should be the whole point of this project - to show real working loader code, and to help demystify the spec.

[probins]

people can be testing out the module tag

this is something that bothers me. I was expecting Chrome to provide the first implementation, but Edge seems to have got there first https://blogs.windows.com/msedgedev/2016/05/17/es6-modules-and-beyond/. If a user has this enabled in the browser, it will process any module tag(s), and in this case the polyfill should not do anything with the tags. But I can't think of any way for the polyfill to know whether this has been done or not. Any ideas?

[probins]

also related to module tag, https://html.spec.whatwg.org/multipage/webappapis.html#integration-with-the-javascript-module-system only allows /, ./ and ../ in module imports, relative to the calling module's base URL. For compatibility, should the polyfill require this too?

[guybedford]

@probins definitely a feature detection can be put together for existing implementations of the module tag. Eg creating a module tag and injecting it into the head it see if it executes.

Yes the module tag restricts names to URL-like. The default loader resolver would implement the same algorithm also throwing on plain names, but then resolver extensions would be able to remove this restriction, as it is exactly designed to be overridden by the ability to set a custom resolver and that is why it is there.

[probins]

injecting it into the head it see if it executes

yes, I suppose it could create a property in System, for example, and then check whether it's been created or not.

ok, I'll start work on a Readme rewrite this week some time. I'll create small PRs rather than one large one.