build target + type

[stefanpenner]

some thoughts, leaving them here for future travelers

---

There is a constant request to expand the number of environment one can use. Although this is perfectly reasonable and internals should (and will support this). I have noticed another similar trend, build targets

• cordova
• nw.js
• electron
• full page web
• embedded web etc)
• etc.
• some custom mode

Ideally, I would like to not see dev_cordova prod_cordova test_corvoda, dev_electron,prod_electron etc.etc. As this quickly becomes entirely unmanageable and the cost of adding a new target becomes quite large. It also becomes tricky when dealing with addons, that maybe only need to do something in testing of Cordova.

One thought I had, was to split the concept into target and type.

• target: destined platform/mode : defaults to web
• type: more similar to todays environment – in-fact it may make sense just to call it environment. : defaults to dev

ember build --target electron --type test
ember server --target electron --type test
ember test --target electron
ember test --target electron --server

This could allow us to provide stable public CLI interface, addon hooks, and should help become a good foundation for future innovation.

---

stuff to explore

• how does one define a target
• how are commands made aware of the target goals
• how do addons work with this.
• how do we merge "goals" of env + target at runtime.

cc people who have been doing related work (based on emberaddons.com search): @mike-north @poteto @rwjblue @jakecraige @juanazam @theodorton @brzpegasus @rmachielse

[rmachielse]

Absolutely interesting! I have solved this problem right now by having a separate directory for the app I want to build. Developers can then symlink the contents of the directory with the real app directory, so they can add files or overwrite them.

Doing this with a target sounds more clean. I think type is a very general name, why not just target and environment?

Still, this means that there has to be a way to add or remove files depending on the target. For example by having extra optional directories per target that will be merged into app on build.

[stefanpenner]

Doing this with a target sounds more clean. I think type is a very general name, why not just target and environment?

no reason, i am fine with either actually. My only concern was migration (unless it turns out --target is merely a layer on top, which is likely)

[stefanpenner]

Still, this means that there has to be a way to add or remove files depending on the target. For example by having extra optional directories per target that will be merged into app on build.

ya this seems easy at the addon/broccoli level (assuming we expose the correct info)

[juanazam]

This makes a lot of sense, the current solutions for this issue are quite troublesome. I'm 👍 with using environment instead of type.

[brzpegasus]

@stefanpenner
One thought I had, was to split the concept into target and type.
This could allow us to provide stable public CLI interface, addon hooks, and should help become a good foundation for future innovation.

That sounds like a good idea. I'd be most interested in what the default Ember CLI commands would do with that information, besides making sure that the app gets built with the right environment configuration (per config/environment.js), and what new hooks this would help expose to addon authors.

If running ember build --environment dev --target foo means the build command could be extended via new hooks to support the specified target without the need for the addon to introduce new commands, that would be pretty awesome. Generally, I find that the core build command or task may work just fine, but I end up creating new commands in order to do something before and/or after the build completes. I'm aware of the preBuild and postBuild hooks, but those are not aware of which command is currently being run (in order to either proceed with custom build steps or skip). We'd need something like preBuildFor(target), postBuildFor(target), or something along those lines.

For example, in ember-cli-nwjs, the ember nw:package command consists of simply running the default build task, then package. Similarly, the ember nw command is the equivalent of doing ember build --watch and running the nw process, but it's a bit more tricky because it needs to spawn nw after the default build task is done, but before invoking the watch promise that never resolves.

I've only just poked around, but I see a similar pattern in ember-cli-cordova's cdv:build command.

Are those the kinds of things you are hoping to provide better support for with the new target and type/environment options?

[stefanpenner]

Are those the kinds of things you are hoping to provide better support for with the new target and type/environment options?

Yes exactly. If you can help assemble detailed scenarios we can likely figure out how to address them with these new hooks.

[stefanpenner]

It seems also useful to make the boot process a public API. The goal would be to parameterize the boot process, allowing different targets to specific everything from attributes, to rootElement to various modes etc.

cc @wycats

[stefanpenner]

this should be ported to a fleshed out RFC

[mixonic]

We discussed this at F2F and I noted the term "target" was similar to "deployTarget" in Ember-CLI Deploy. http://ember-cli.com/ember-cli-deploy/docs/v0.5.x/usage-overview/ Maybe it is a good thing to coordinate on as we make this an RFC @stefanpenner @lukemelia @achambers

[achambers]

We moved from environment to deployTarget as we wanted to keep a clear separation between what was an ember-cli build environment and what was a deployTarget. Would be great to keep this separation clear. 👍

[runspired]

Only just discovered this RFC thanks to @brzpegasus

I've been formulating ember-cli-platforms as a concept for a long time, and began final sketches heading into implementation this week for work at IsleofCode. We're intending to move fairly fast.

IsleofCode has picked up ember-cli-cordova, has internal stuff used for chrome/firefox extensions, and I've talked with @felixrieseberg @achambers and @brzpegasus about the implementation as it concerns sharing / working with ember-cli-deploy, ember-electron, and ember-cli-nwjs.

I would love additional feedback on the sketch (it's just a readme) from @lukemelia @stefanpenner @mixonic and whomever else is currently pondering this over.

Proposal