[QUEST] Initial implementation

[simonihmig]

Overview

• the previous approach with a custom broccoli builder/watcher (#1) was dismissed, the addon mostly rewritten
• uses a simple middleware to serve the /_analyize URL
• upon first request serves a loading page, that redirects to /_analyze/compute
• that in turn triggers the creation of the stats output (provided by broccoli-concat-analyser). It uses the CONCAT_STATS_PATH if available (as of broccoli-concat 3.6.0) to tell broccoli-concat to output in a temporary folder. Once that's ready, it returns a redirect response back to /_analyze
• as the output is now available, it gets served immediately, and remains cached for subsequent reloads
• a sane based file watcher invalidates the cache when a .json output file is changed. A subsequent reload by the user would trigger the above process (loading page, stats generation, stats display) again

Remaining issues

• [x] the addon enables CONCAT_STATS by default (https://github.com/simonihmig/ember-cli-concat-analyzer/blob/master/index.js#L21). Doing that for the first /_analyze would be better, as broccoli-concat would not need to generate the stats files all the time by default. A test to set the env var and triggering a rebuild (by touching e.g. app.js) did not work out, as setting the CONCAT_STATS after the plugin instantiation is too late for the current implementation in the constructor (see https://github.com/broccolijs/broccoli-concat/blob/master/concat.js#L28-L32). Enabling that would require some further changes there... Fixed in https://github.com/simonihmig/ember-cli-concat-analyzer/commit/c9b27f257c6bbfb7ba58a8425db46865e1ddeaab

To Do

• [x] Tests
• [x] Docs
• [x] Livereload support?

[simonihmig]

@stefanpenner mind having another look if that makes sense so far? Any thoughts?

[stefanpenner]

we can bikeshed the name abit.

• _ember-cli
• _ember
• _build <- my preference so far
• _analyze

I would like to slot in more utilities at this namespace, utilities such as heimdall viz, and some tools merely an idea. So whatever we do, lets try to make it somewhat future friendly.

[stefanpenner]

but otherwise the above LGTM

[simonihmig]

IIUC the idea is to have different addons mount their middleware under a common namespace (that needs to be distinct from any user's routes, hence the underscore), like _build, right?

This sounds good. I just played a bit with the new vue-cli, they have put together quite a nice web UI layer... (see https://cli.vuejs.org/guide/cli-service.html#using-the-binary). Maybe ember could go into that direction somehow/sometime as well? Certainly out of scope for this discussion here, rather something for a bigger RFC. But assuming there is a future for something like this, I would guess this could integrate not only build tools. E.g. a way to run the given blueprints using a web UI. Or installing addons.

So I think I would prefer _ember, as that could map to known CLI commands (or at least be more "open-ended"):

• _ember/generate...
• _ember/install...
• _ember/test
• _ember/bundle-analyzer

BTW, I was thinking of renaming this addon to something like bundle-analyzer, as that is how these tools are known in the wider (webpack/react) ecosystem, and is more agnostic of the underlying implementation (concat)...

[nightire]

BTW, I was thinking of renaming this addon to something like bundle-analyzer, as that is how these tools are known in the wider (webpack/react) ecosystem, and is more agnostic of the underlying implementation (concat)...

I agree, concat-analyzer is the kind of name you often can't remember...