"new" command implementation about ember-cli

[joliss]

Yes, that isn't implemented yet.

What are we going to use for generators btw? I know we were talking about loom, but Tyler Kellen also suggested that yeoman is good at generating stuff.

[tgsoverly]

https://github.com/yeoman/generator-ember. The little yeoman is holding an ember box! ;-) They actually have a issue in there worth a look. https://github.com/yeoman/generator-ember/issues/102 It does seem a little silly to generate the entire build stuff all over. Seems like cli could delegate to the generator, for anything in "new".

One of the most annoying things I find with "non-official" build tools is the lack of consistency in commands. This even annoys me with rails to some extent. having to remember when to use "rake" and when to use "rails", coming from a mostly java shop we use grails/gradle, and all commands run through the "grails" or "gradle" commands, and it is nice. So the (long winded point) is I think the yeoman looks good, but at the very least should be wrapped under an "ember" command.

[tgsoverly]

I have been playing around with that yo generator. It is pretty complete but it was pretty touchy for me. Requiring some pre-requisites like ruby and compass gem. I would consider multiple languages a minus. I will keep looking around and maybe throw up a rough pull-request for discussion.

[joefiorini]

I think the goal is to avoid using Yeoman. While it's a great library, it comes with a ton of dependencies and asks a lot of questions that we don't really need.

I was just giving this some thought and I think an initial implementation could just copy files/folders from a default skeleton to cwd. The only option would be the app name, which could get interpolated into the package.json and a couple other places where 'appkit' is currently hard-coded.

I think eventually it'd be cool to support additional skeletons that can be included in plugins. The primary use case for this is to allow ember-cli to be used as a build tool in server-side environments that don't already have a better option (eg. Django, ASP.NET MVC, etc). @stefanpenner what do you think of skeletons in plugins?

[tgsoverly]

After looking into yo. I would agree in agree in avoiding it.

Sent from my iPhone

On Feb 8, 2014, at 1:03 PM, Joe Fiorini [email protected] wrote:

I think the goal is to avoid using Yeoman. While it's a great library, it comes with a ton of dependencies and asks a lot of questions that we don't really need.

I was just giving this some thought and I think an initial implementation could just copy files/folders from a default skeleton to cwd. The only option would be the app name, which could get interpolated into the package.json and a couple other places where 'appkit' is currently hard-coded.

I think eventually it'd be cool to support additional skeletons that can be included in plugins. The primary use case for this is to allow ember-cli to be used as a build tool in server-side environments that don't already have a better option (eg. Django, ASP.NET MVC, etc). @stefanpenner what do you think of skeletons in plugins?

—
Reply to this email directly or view it on GitHub.

[stefanpenner]

@joefiorini I share your concern.

I am unsure what value the skeleton projects provide, other then example/tutorial/mindshare sharding. I would prefer to see us pave the other paths, without needing to generate different structures.

One thing that may make sense, is something similar to rails templates.

[joefiorini]

The idea behind different skeletons is to support embedding ember apps in server-side apps. Kind of like ember-appkit-rails. We don't need to support the specific frameworks, just allow others to write plugins that would make it easy to support the conventions of other frameworks. I think this could go a long way in helping devs in any framework integrate ember apps into their framework with minimum friction. Also with a minimum of work/support from the Ember team. Does this make sense?

[joefiorini]

WRT to generating structures, I think we'd be okay writing our own until we really feel the need for something more advanced. @tgsoverly I have a pretty good idea how to implement this quickly, I was going to work on it this afternoon. Do you mind if I go ahead or have you already started making progress?

[stefanpenner]

@joefiorini seems good for us to keep in the back of our mind.

[tgsoverly]

@joefiorini I didn't really make any progress worth reviewing, I spend a bunch of time coming to the conclusion that the yo stuff wasn't worth it. So feel free to do it, because I won't this weekend!

@joefiorini @stefanpenner I have also recently been giving this issue of skeletons and using ember inside of other frameworks a lot of thought, because this is something I need at work. I would love to be able to develop an ember app on its own, but include it as a dependency in other applications with some minimal configuration.

What I would love to see over skeletons is the ability to quickly build and publish a build of your ember app to say a private bower registry or bower like registry. Then you are much more framework independent, because lots of frameworks could pull in the app through their own bower plugins. What do you think about that idea?

[tgsoverly]

And I hope i am not being to forward with my opinions.

Sent from my iPhone

On Feb 8, 2014, at 2:59 PM, Stefan Penner [email protected] wrote:

@joefiorini seems good for us to keep in the back of our mind.

—
Reply to this email directly or view it on GitHub.

[tgsoverly]

And that is "way" off topic from the "new" command, and I saw a pull request so I am closing this issue.