lib/broccoli/ember-modules-app

[nathanhammond]

The existing lib/broccoli/ember-app has a lot of organically grown behavior which supports our needs at present but doesn't give us as many opportunities to grow for the future. We're going to need to do some work in this area to support the new module unification RFC and this gives us as good a reason as any to ensure that we start this process off on a good footing.

A lot of these pain points have been discovered in the development efforts for FastBoot and Ember Engines and last year's efforts toward a linker/packager.

Goals

• Have a specification for the inputs and outputs at each step of the build.
• Support the Module Unification RFC.
• Allow for parallelization of Babel, Uglify, other pre- and post-processors.
• Support Babel external helpers.
• Stable output per module if it doesn't change. (Minify on a per-module basis.)
• Support inclusion (or fail gracefully) when encountering addons at different version numbers.
• Don't merge things down until as late as possible to reduce unnecessary rework.
• Support multiple "root" entry points (host application, lazy engines, ___).
• Build a foundation for linker/packager and "graph" shaking.
• Have a built in story for Browserify/ES6 node module inclusion.
• Provide hook which allows for "preparse" and rollup behavior.
• Recursively inline leaf node dependencies which are only required by a single module.
• Support building ember.js as an addon in a "fast" way.
• Support multiple build targets (e.g. fastboot).
• Define a noConflict story for globals code included in nested addons.
• Add backwards compatibility in as a last step (focus on the future use case).
• Capture asset size at a different place before concat.
• Provide reasonable "affect the parent" hooks.
• Extract most processing into addons.

Is this a complete enumeration of our goals? What else do we need to address in this effort?

/cc @chadhietala @danmcclain @dgeb @lukemelia @rwjblue @stefanpenner @tomdale @Turbo87 @twokul

[Turbo87]

Add backwards compatibility in as a last step (focus on the future use case).

can you clarify that? not sure how to understand this...

[nathanhammond]

@Turbo87 We clearly require an interoperability story here. However that should not be a primary consideration at the beginning of this effort. I want for our first step to be, "given what we know from the years of experience we have in this problem space, this solution is closest to our ideal." Once we know what our ideal is, we can work backwards to identify how best to migrate our users to that solution.

For those following along more casually let me emphasize again that there will be a compatibility story and a migration story. This is integral to the commitments we make in maintaining Ember CLI and the community. The approach we take to building this does not in any way change our support promises.

[stefanpenner]

It is worth saying, this is largely a spike to figure out what we want. We will then work back and figure out how to support it. Not that we will implement ship then try and figure out compatibility.

[danmcclain]

I started working on the new resolver (mostly around determining which module and export we need to look up based on the internal module manifest) here: https://github.com/danmcclain/ember-resolver/blob/new-resolver/tests/unit/new-resolver-test.js

Few things I need to still cover on it, but wanted to surface what I have