-
Notifications
You must be signed in to change notification settings - Fork 185
Conversation
@@ -73,7 +81,7 @@ | |||
}); | |||
|
|||
else if (stage == 'link') | |||
return requestLink(loader, key, metadata).then(function() {}) | |||
return requestLink(loader, key, metadata).then(function() {}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We do need this semicolon?
I'd rather not just remove this code actually. Better to get the tests running then move through code changes that keep the tests running. Otherwise the codebase will drift off too much - it then becomes as good as a rewrite getting the tests going eventually. |
(Happy to take comment PRs that update the function numbers, note spec deprecations though) |
although in principle I think it would be better to start from scratch, in practice I'm not sure that will work, as I doubt whether I will have time to do more than a small part of what needs doing. I can do some work over the next couple of weeks, but after that I'm not sure. So an incremental approach might be better, but I'm not sure how that would work either, as changing for example Loader.prototype functions means you have to implement the new functions called by those functions, which for the most part don't currently exist or need rewriting. The Registry functions should be reasonably straightforward to implement, so perhaps we could start with that. But to get the tests working, the environment needs changing - later version of Node, include URL in Node version including Travis, module-only version of Traceur/Babel (what about Typescript?), catering for As for the missing semicolon, this is something the linter in my editor complained about. I think it would be better for Travis/the build system to run a linter, but presumably it doesn't atm because of the way the code is split into different files and concated into a wrapper. So perhaps converting to ES6 modules and using Rollup to convert into IIFE should also be a priority? For the time being, I'll change this PR to be comments only. I'll list in the comments for each function which other functions it runs/is dependent on. I'll also try and draw up some task lists. Rather than preface all these with '0.50', it might be better to create a new Github label and/or milestone for this. I could do this, but because of Github's limited permissions system would have to have commit rights to the repo - otherwise you would have to do it. |
@probins whatwg/loader#147 changes things significantly now so I think we should put this effort on hold until that clarifies. It does sound like that will be largely a rewrite direction, so I will aim to jump into this work as soon as it becomes possible now. |
yes, I noticed that, though it's all rather vague atm "not an actual plan, just food for thoughts" |
might as well close this for the moment |
Now to plan that upgrade path :) |
@guybedford I'm not sure it does, does it? It changes what is exposed to users, but AIUI the basic |
@probins if you do want to continue working on PRs based on the new directions I guess we can do that too. |
shan't have time this month; perhaps in August. So if you have time to work on this ... |
I've been working on a rewrite already of just the shell API for a fast
|
Nothing against Joel's work, of course, but I'm seriously wondering whether it wouldn't be simpler to start from scratch. I hadn't realised that the spec had changed so much.