search

google / traceur-compiler

Traceur is a JavaScript.next-to-JavaScript-of-today compiler
Apache License 2.0
8.17k stars 578 forks source link

traceur-runtime.js no longer polyfills window.System #2113

Closed jarek-foksa closed 8 years ago

jarek-foksa commented 8 years ago

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?

jarek-foksa commented 8 years ago

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.

UltCombo commented 8 years ago

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.

jarek-foksa commented 8 years ago

Ahh, right. Also, when there are breaking changes, the "x" in x.y.z should be bumped, not "y". Makes sense now.

johnjbarton commented 8 years ago

@jarek-foksa can you please post more details on how you were using traceur?

jarek-foksa commented 8 years ago

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.

johnjbarton commented 8 years ago

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 https://github.com/google/traceur-compiler/commit/412a09e2f3728e5ddf66c273ed83bac577d00b88 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).

jarek-foksa commented 8 years ago

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?

johnjbarton commented 8 years ago

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.

jarek-foksa commented 8 years ago

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).

johnjbarton commented 8 years ago

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: https://github.com/google/traceur-compiler/commit/1bccc342cd0de8315200bee771379b0f4e888835

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?

jarek-foksa commented 8 years ago

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.