Impacts Build performance negatively

[stefanpenner]

This has been brought up in chat, but i can't seem to find an issue. If there is one, and I missed it feel free to close.

More concretely it appears this add-on at-least duplicates the build, causing ember-twiddle for example to for example browserify (and everything else) twice.

Specifically these area is one of the offenders:

• https://github.com/ember-fastboot/ember-cli-fastboot/blob/master/index.js#L130-L139
• https://github.com/ember-fastboot/ember-cli-fastboot/blob/master/index.js#L120-L125

[danmcclain]

Related issue: #159

[stefanpenner]

Currently, it builds the whole app twice. Once for browser and once for Fastboot. This has many issues, the most obvious is developer ergonomics (doubling our build costs, isn't acceptable) the less obvious issues are different builds === different bugs, harder to debug etc.etc, another permutation here makes all future efforts that build on this also more complicated.

The problem specifically is:

ember-cli-fastboot/index.js

Line 121 in bb8c4bf

var fastbootTree = this.buildFastBootTree();

• tree: is the already built app
• fastbootTree: is a second build (of nearly the same app) + fastbootisms

The majority of the system is the same between both worlds. With the exception of some custom fastboot replacements/configuration.

Current these faceboot replacements are very coupled to the app, but this does not need to be. If decoupled, we will most likely have simpler and more performance system.

If instead we did the following:

1. Build the app.js like we do today (maybe minor tweaks)
2. Build app-fastboot.js as an additional set of AMD modules that adds new or replaces existing modules
3. The node vm running fastboot, merely loads (app.js) then loads (app-fastboot.js) and then finally starts the app, the AMD modules will merge as expected.

Anything that prevents this from working, we should identify and come up with targeted solutions.

For example. app/fastboot and having fastboot initializers mixed into app, unnecessarily complicates the build. Instead moving fastboot to a sibling of app, allowing it to have its own pipeline (it is going to run in node after all)...

That pipeline for fast-boot stuff, could be something relatively simple:

var Concat = require('broccoli-concat');
var Funnel  = require('broccoli-funnel');
var Babel = require('broccoli-babel-transpiler');
var amdNameResolver = require('amd-name-resolver').moduleResolve;

var fastboot = new Funnel('fastboot');
var es5 = new Babel(fastboot, { // options extracted from how ember-cli does this
  compileModules: true,
  modules: 'amdStrict',
  moduleIds: true,
  resolveModuleSrouce: amdNameResolver
});

// likely other files and stuff
var fastboot = concat(es5, { outputFile: 'app-fastboot.js' });

I believe above could essentially replace the existing buildFastBootTree

Objectives

• unblock fastboot build performance issues
• keep the system simple (mark small strategic changes anywhere needed to keep the system simple and performance)

Acceptance Criteria

• no build regression
• easy to reason about, implment and extend.

Pre-Reqs

• identify problems that prevent the above proposal, such that they can either be fixed or the proposal can be updated.

[stefanpenner]

Its worth pointing out, I have little time to actually do ^ but I believe @kratiahuja and some other co-workers (whos GH names I don't know) are exploring this further.

That being said, if all else fails I am available to help be a sounding board, or help unblock.

[kratiahuja]

@stefanpenner I'll work on this.

[danmcclain]

I'm also interested in contributing to this

[kratiahuja]

@danmcclain I'll sync up with you next week once I have a prototype running by end of day today. We can create a PR with action items and start fixing this. We also need to fix the express server that fastboot creates.

[kratiahuja]

@stefanpenner @danmcclain

I did a spike of what Stef suggested on an app and it definitely shows reduced build times than on an app having ember-cli-fastboot.

The spiked app is here. Look at ember-cli-build.js.

I am going to spend next week to come up with a plan such that ember-cli has a public API to allow additional pipelines during ember build. We also need to come up with a story of how to address fastboot in addon namespace.

[kratiahuja]

Synced up with Stef offline. I am going to do a spike of this in ember-cli and then open a PR with the list of things we need to address including the public API to expose.

[kratiahuja]

cc: @masonwan @ryanone

[kratiahuja]

I am done with a spike in ember-cli and I have a list of things that we need to expose from ember-cli and things need to be fixed in ember-cli-fastboot to welcome "fastboot in ember-cli".

I will open an issue tomorrow morning in ember-cli and here to describe the work task. Stay tuned!

cc: @tomdale @danmcclain @arjansingh @stefanpenner @masonwan @ryanone

[kratiahuja]

Here is the issue with all details tracking in ember-cli. Please feel free to comment and give feedback.

Once most of the folks agree on the ember-cli issue that this is the way to move forward, I will open an issue in this repo with the list of tasks that need to be done to using building fastboot with ember build.

[stefanpenner]

master (soon rc.1) should address this