Pull Ember CLI Deps In As A Monolithic Addon

Ember CLI
1

Problem

You want to globally manage all of applications runtime dependencies e.g. Ember, Handlebars, jQuery, Resolver, etc as a unit for many instances of Ember applications. This allows you to only have 1 vendor file across all of the application instances in your CDN. Currently each Ember CLI instance has it’s own version of Ember.

Potential Solution

Have Ember CLI instances depend on an addon that provides the framework files and use the customHash for fingerprinting that points to the same CDN hash across the applications. This allows you to have the cached vendor files across multiple applications.

Can this be done? What are the downsides of this? Does this seem reasonable?

2

the problem is each app has a slightly different vendor so they fingerprint differently, and the goal is to instead split the assets across multiple files that change/deviate infrequently ?

3

Yes so there are things that change infrequent but are required to run an app e.g. jQuery, Handlebars, Ember, etc. But each application instance with CLI pulls these from bower and builds them. This means you have N number of compiled framework files in CDN which is largely the same code. Ideally you have a baseline of things every application needs and they all point to the same files in the CDN.

4

Getting into more LinkedIn specific implementation, our CDN can take a url that looks like

http://scds.linkedin.com/h/#MD5,#MD5,#MD5

And concat the contents of those MD5 hashes. This means if something is already in the CDN all I need is to build a URL with the MD5 hashes and I get them. This is super cool for things like web components / UI addons because then I just need the hash to the thing I want and don’t have to worry about pulling the files in locally.

5

do you see splitting your vendor into logical groups or chunks? Per file? Per group of files?

6

i suspect that per “vendor” bundle isn’t granular enough for you to get savings.

But many

jquery + handlebars + ember + ember-data (all at specific versions) would make a good bundle for you?

7

i think that your idea is interesting, but it seems like you would prefer to have dist/assets/ contain the groups you expect, which are then submitted to your CDN. if there exists such a group already you will join it, and share that asset entry.

If your group does not exists you will add a new entry.

The benefit of this is purely flexibility of the developer (say they need a custom build, they no longer need to coordinate with a CDN derived add-on to ensure there deps are in the cloud).

The cost is, if minor revisions exist between apps, they will not sure CDN resources.

In theory if vendor.js was split into more logic chunks that change in unison. With this, the solution seems relatively straight forward.

8

This is possible via an addon. Steps are something like:

  • remove the default vendor script tag in the blueprinted index.html (see here)
  • add a custom script tag for vendor.js file in the contentFor hook
  • export the custom URL in your addon’s treeFor hook (could also use treeForPublic or treeForVendor etc)
  • Use this addon’s versioning to keep your fingerprinted shas correct for production (and publishing to CDN)
9

@rwjblue i wonder if splitting and allowing emergent bundles to form is sufficient and more development ergonomic.

10

Yea I think logical chunks for vendor is what I’m getting at. There are 3 levels/types of assets in an application.

  • Application: Lot’s of churn
  • Application Specific Framework Files: Think 3rd party addons, little churn but application specific
  • Framework Files: Things that have little churn and universally needed across all apps
11

so it seems like the ideal solution is being able to declare vendor groups, dist include those groups as separate files. Then you can CDN those groups. (I suspect other people may also want this.

12

We have the same requirement. We have multiple ember apps built through ember CLI and we would like the framework files to be pulled from a common addon. Would ember CLI support the concept of “vendor groups” in the future? How do you stop an app from building the core dependencies into vendor(ember, handlebars et al)? At the moment, removing these dependencies from bower.json breaks the build process