search

ember-cli / rfcs

Archive of RFCs for changes to ember-cli (for current RFC repo see https://github.com/emberjs/rfcs)
45 stars 54 forks source link

RFC to build fastboot in ember-cli. #77

Closed kratiahuja closed 5 years ago

kratiahuja commented 7 years ago

rendered

Corresponding PR which does the work described in this RFC is here.

Long term RFC which should allow this to become a generic feature is described in this RFC

cc: @stefanpenner @tomdale @rwjblue @ryanone @masonwan @kristoferbaxter @arjansingh

kratiahuja commented 7 years ago

Some history are mentioned in the following issues:

  1. ember-cli issue
  2. ember-cli-fastboot issue
kratiahuja commented 7 years ago

I would have thought that we would want a browser/app and browser/addon. This way the main generic app bundles live in addon or app and the "platform specific" parts live in either browser/ or fastboot/. The resulting build would have app.js, browser-app.js, fastboot-app.js, and possibly a combined-app.js (which would be the main app bundle along with the main browser bundle).

I agree about this as a "long term" goal (see this RFC). If we want to do this with this RFC, it then it means this is a backward incompatible change in ember-cli. The goal of this RFC was:

  1. Keep ember-cli backward compatible
  2. Do not regress the current ember-cli builds that builds browser specific assets.
  3. Do the minimal things in ember-cli such that FastBoot 1.0 is unblocked.

If everyone agrees to the above scope of the problem, this this is what this RFC is supposed to address.

kratiahuja commented 7 years ago

Is there a specific reason to rely on the "last module registered wins" clobbering behavior as opposed to relying on broccoli-merge-trees (with { overwrite: true }) to allow only the final concat to differ?

No specific reason, that is how loader.js works today. We can do the final merge of app.js and app-fastboot.js but this is a behavior I would leave upto the platform to determine. (In case of fastboot, ember-cli-fastboot can do that in the postProcessTree for fastboot type).

kratiahuja commented 7 years ago

@rwjblue updated per your feedback.

kellyselden commented 7 years ago

I read through the spike in https://github.com/ember-cli/ember-cli/pull/6395, and it seems like it is so close to being independent of fastboot, all it needs is a supplied "platform".

preprocessTree could change from receiving "app-fastboot" to "app-[platform]" postprocessTree could change from receiving "app-fastboot" to "app-[platform]" treeForFastBootApp could change to treeForAppPlatform with a param "type" of "[platform]"

An app or addon could then supply an array of platforms, via ember-cli-build.js or package.json, and ember-cli would look for folders with those names. Then the rest of this RFC would take effect.

rwjblue commented 5 years ago

We are working on closing the ember-cli/rfcs repo in favor of using a single central RFC's repo for everything. This was laid out in https://emberjs.github.io/rfcs/0300-rfc-process-update.html.

Sorry for the troubles, but would you mind reviewing to see if this is still something we need, and if so migrating this over to emberjs/rfcs?

Thank you!