search

ember-cli / rfcs

Archive of RFCs for changes to ember-cli (for current RFC repo see https://github.com/emberjs/rfcs)
45 stars 54 forks source link

ember-cli platform flag and platform support #35

Closed runspired closed 5 years ago

runspired commented 8 years ago

Intended to supplant #26 rendered

This was extracted from an addon proposal, and there are areas (testing, how to handle security concerns of some platforms, and how to expose the pipeline to plugins) that would evolve overtime in an addon and are less fleshed out from the perspective of being an addition to ember-cli than they ought to be.

Addon where this is likely to be built initially

kellyselden commented 8 years ago

I didn't see anything about supported platforms. Would ember-cli come built in with any platforms, or just the base platform command with no implementations. Would the current ember-cli system be refactored into a default (implicit) platform of "web-app"?

Turbo87 commented 8 years ago

Would ember-cli come built in with any platforms, or just the base platform command with no implementations.

If I understood correctly ember generate platform cordova --name=ios would try to install ember-platform-cordova automatically and then use it to generate the necessary files

Would the current ember-cli system be refactored into a default (implicit) platform of "web-app"?

Since the usual "web-app" has no other special tooling needed it should probably stay the default. I think it's also still the 90% use case so that should be as simple as possible, which also means not bothering dev with the "platforms" concept as long as they don't need it.

runspired commented 8 years ago

@Turbo87 @kellyselden no platforms come built in, the idea is to expose the right hooks and flags so that a platform plugin can be individually developed for each platform that can rely on a standardized setup and process instead of needing a unique DSL and much "guts" code repetition for these things.

Would the current ember-cli system be refactored into a default (implicit) platform of "web-app"?

Yes. End user's (addon app creators) wont see any change in code organization, but running any command without the platform flag would be the equivalent of running it with the "web" flag.

If I understood correctly ember generate platform cordova --name=ios would try to install ember-platform-cordova automatically and then use it to generate the necessary files

This is up for debate. I think it should be the case, but that might be over greedy and lead to an undesirable level of complexity.

Turbo87 commented 8 years ago

This is up for debate. I think it should be the case, but that might be over greedy and lead to an undesirable level of complexity.

I think I would prefer something like this:

ember install ember-platform-cordova
ember generate cordova-thingy android

It's not much more difficult than the proposed command but leverages a lot of the existing code and concepts.

runspired commented 8 years ago

I'm going to leave this as a comment as I haven't had time to update the RFC.

For this RFC, we will need to make sure to:

We likely should enable:

After conversations with @brzpegasus @stefanpenner @lukemelia and @felixrieseberg, it looks like this RFC has surfaced a number of common addon needs that are larger than the scope here, and potentially could become 3 RFCs.

"middleware hooks" -> addon hooks for testem options -> custom testem launchers -> customize build, and watch including with a custom index.html for the tests

The short and dirty solution for this for the near term is to allow platform plugins to extend or replace tasks more easily.

"install patches" -> ability to "patch" modify

runspired commented 8 years ago

@Turbo87 We would still be able to leverage the existing code, but I do agree with the sentiments of not expanding the surface area. Possibly another way of achieving this elegantly would be.

ember install ember-cli-platform-cordova --name="ios"

Where that flag is passed into the default blueprint, and (I'm pretty sure) that capability already exists.

Turbo87 commented 8 years ago

"install patches"

I don't think there's anything stopping you from doing this right now, there's just no API available for e.g. reading/writing markdown. or are you talking about applying actual patch/diff files?

Turbo87 commented 8 years ago

ember install ember-cli-platform-cordova --name="ios"

but then you need a different command if you want to add a second cordova target... I'd try to keep it as simple as possible. install for installing the addon, generate for generating a target/platform/whatever it's called.

runspired commented 8 years ago

@Turbo87 since install runs the default blueprint, we'd be assuming that

ember g platform cordova --name="android"

would actually be the same blueprint.

runspired commented 8 years ago

@Turbo87

there's just no API available

Correct. @stefanpenner and I both feel there's value in having an official API available. I've done this in the ember-cli-toolbelts experiment, and would love to expand on that work and give it a nice API.

Turbo87 commented 8 years ago

@runspired I know that it could technically work. I'm just saying that as an end user of such an ember-platform-cordova addon it would be easier to grasp if the commands were separate :wink:

Turbo87 commented 8 years ago

there's value in having an official API available.

I don't see how that is the responsibility of ember-cli. IMHO it should give blueprints and/or addons a hook after the files are written so that they can be processed if needed, but writing markdown or something like that seems out of scope for me. there are probably libs on NPM that could do that but I don't think they should be part of every ember-cli install for the few addons that actually want to modify a default readme file.

kellyselden commented 8 years ago

Since the usual "web-app" has no other special tooling needed it should probably stay the default. I think it's also still the 90% use case so that should be as simple as possible, which also means not bothering dev with the "platforms" concept as long as they don't need it.

@Turbo87 I wasn't suggesting people would have to run extra commands, just that ember-cli internals use the platform system to generate the "web" platform implicitly, similar to @runspired 's comment:

Yes. End user's (addon app creators) wont see any change in code organization, but running any command without the platform flag would be the equivalent of running it with the "web" flag.

nathanhammond commented 8 years ago

IMHO it should give blueprints and/or addons a hook after the files are written so that they can be processed if needed, but writing markdown or something like that seems out of scope for me.

@Turbo87 @runspired See: https://github.com/ember-cli/rfcs/issues/36

We're basically discovering that, if we want to keep code out of ember-cli core, we need to carefully design extensibility patterns for each major ember-cli construct. That discovery was echoed again in today's meeting.

nathanhammond commented 8 years ago

At the conclusion of today's team meeting we were unanimous in the opinion that this is the wrong level at which to attack this problem. The underlying problem here isn't that we need ember-cli to support a new type of behavior, but instead that modifications to ember-cli are required to support this type of behavior. It's our goal that something of this nature should be possible to accomplish inside of an addon without requiring the present amounts of copypasta, clever imports, and monkeypatches.

At this point we know very well that it is impossible for us to do much more than make educated guesses as to how people wish to use ember-cli, and who knows what our Angular friends will discover in their world. With that context, our work on ember-cli needs to be responsible for a few things:

In order to achieve the last one we discussed identifying/designing what the core extensibility primitive is inside of ember-cli for each of the main components. This is similar in what was discovered with Broccoli where everything along the way simply receives a tree. It's unlikely that we do as well in creating such a beautifully simple primitive to accomplish the entire functionality, but that should be the measuring stick by which we evaluate our solution for elegance.

With that, @runspired, I motion to close this in favor of a different RFC (or multiple RFCs), yet to be written. If you agree we'll close this PR. :smile:

rwjblue commented 5 years ago

We are working on closing the ember-cli/rfcs repo in favor of using a single central RFC's repo for everything. This was laid out in https://emberjs.github.io/rfcs/0300-rfc-process-update.html.

Sorry for the troubles, but would you mind reviewing to see if this is still something we need, and if so migrating this over to emberjs/rfcs?

Thank you!