traceur-runtime.js no longer polyfills window.System
jarek-foksa opened this issue · 11 comments
After updating to the latest version of Traceur, I have noticed that I'm no longer able to use window.System.* API. As usual, this breaking change does not seem to be documented anywhere.
What is the migration path? Should I just add "window.System = $traceurRuntime.ModuleStore;" at the end of traceur-runtime.js?
BTW, I would suggest using semantic version numbers as defined on semver.org, i.e. when you introduce breaking API changes, increment the version number from 0.0.108 to 0.1.0, not from 0.0.108 to 0.0.109.
Re: semver, version 0.x.x is special and has no semantic meaning. As per semver.org:
Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.
The ideal path would be for Traceur to bump the version to 1.0.0, as to signal a compromise with semantic versioning, and then correctly follow it.
Ahh, right. Also, when there are breaking changes, the "x" in x.y.z should be bumped, not "y". Makes sense now.
@jarek-foksa can you please post more details on how you were using traceur?
I'm using Traceur NPM package. I'm compiling scripts with "modules" option set to "bootstrap". I'm no longer able to use System.* APIs after updating the package to the latest version.
Thanks for the info, but I think that this issue is not about the API (which -- depending on what we call our API -- didn't change). Rather I think we re-organized how we do browser bootstrap for our own demos. I'm guessing that perhaps you are using the same approach?
If you look at some of the test files in
412a09e
you'll see we don't use traceur.js but rather the BrowserSystem.js.
Does this help?
(I think we are a bit too flexible in having so many ways to use traceur. One consequence is we often don't know what our effective API really is).
traceur/bin/BrowserSystem.js works fine, but it is ten times bigger than traceur/bin/traceur-runtime.js and it takes 300-400ms longer to load. Are you planning to stop shipping traceur-runtime.js in future?
traceur/bin/BrowserSystem.js includes traceur/bin/traceur.js and the latter includes traceur/bin/traceur-runtime.js. It is approximately the same size as traceur/bin/traceur.js which you need to use the compiler code you posted.
On the other hand, you don't need traceur/bin/traceur-runtime.js with traceur/bin/traceur.js (or traceur/bin/BrowserSystem.js). So the combination of needing both the compiler and traceur/bin/traceur-runtime.js is confusing to me.
Maybe you are compiling offline with a custom compiler and using the runtime in the browser? We just need to figure out how you were getting window.System before in that scenario.
I'm compiling ES6 files to ES5 files using Node.js+Traceur. Then I'm lading the compiled ES5 files in browser. Besides the compiled scripts, I used to provide only traceur-runtime.js to the browser (it was polyfilling window.System).
I'm pretty sure that we didn't have TraceurLoader (the base class for our System) in bin/traceur-runtime.js, but at one point we did generate our bootstrap code with System.registerModule(). Then we changed to use $traceurRuntime.registerModule() to avoid System to help systemjs project. That must be the point that caused your issue:
1bccc34
According to how we use the compiler and runtime I would not expect you to need window.System now. Can you tell me what kind of error you get or why you need window.System?
Previously I was using Traceur version 0.0.92, so I guess the commit you mentioned was the turning point.
I need System.get() in order to avoid circular dependencies by loading modules dynamically in function body.
I have replaced all calls to System.get() with $traceurRuntime.getModule(), which solved the problem.