How do I keep my app built with ember-app-kit up to date? about ember-app-kit

[joefiorini]

How would one customize build options if needed? It seems like that might be difficult, would it better to break up ember-app-kit into NPM modules of grunt asks preconfigured for Ember defaults?

[joefiorini]

I've been thinking about this a bit as I have a library where I need to do something similar to EAK (also see my proposal for option 2 below for a better description of the problem). I've come up with a couple options here:

1. Grunt Wrapper

This is the approach that Lineman takes. It provides its own executable (lineman) and delegates commands to grunt. Lineman configures itself within the NPM module. To set any explicit configuration, you have to do it in config/application.js. The problem is, I know grunt and have configurations for most of the tasks that Lineman uses. I'd rather just override task options in a Gruntfile and be done.

2. Built-In

This is a larger proposal that involves creating a new task to load options from NPM modules (essentially extracting @stefanpenner's loadConfig function), but would allow a user to include EAK as an NPM module and then override settings in their own Gruntfile. Ideally I'd like to take this idea to the Grunt team and try to make these methods on grunt itself, but want to get some feedback on the general idea first. See the gist of the proposal.

3. Another Option

One other option I see is to create our tasks that wrap the tasks we're including, and supply custom configuration for them. For example, EAK's grunt build task could be configured with a handlebars_template_paths option specifically for overriding the default template lookup. This would put control of customizability into the hands of the module-author, not the user, which may or may not be ideal. I think I'd prefer to just override the tasks' options myself, in case, for eg. I want to change the Sass output syntax.

Thoughts?

[ryanflorence]

well .. it is a git repo with an upstream, so we could just take care to say "these are parts of the kit, avoid them to avoid merge conflicts".

One of the issues of ember-tools is that it isn't standalone so you are tied to my release schedule which is terrible. I do not want to see ember app kit have the same problem by hiding all the tooling behind an npm module.

[stefanpenner]

I think this is worth keeping on our mind, but seems tough without massive compromises. At least today.

[joefiorini]

Me either, I've currently been using the upstream method to keep it
up-to-date. It's only slightly painful since there are somethings we've
had to customize (eg. using grunt-connect-proxy to run our rack-based
fake API through grunt).

On Thu, Sep 5, 2013 at 10:11 PM, Ryan Florence [email protected]:

well .. it is a git repo with an upstream, so we could just take care
to say "these are parts of the kit, avoid them to avoid merge conflicts".

One of the issues of ember-tools is that it isn't standalone so you are
tied to my release schedule which is terrible. I do not want to see ember
app kit have the same problem by hiding all the tooling behind an npm
module.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/24#issuecomment-23914809
.

[thomasboyt]

agree on not hiding anything. visible boilerplate > hidden tasks; learned that from grunt-microlib.

i think upstream strategy is good for now, maybe could add a bit to docs about it. ember create executable could do something like yeoman, where it prompts whether you want to overwrite for each changed file. hell, maybe we could even have it update by using the git repo and doing some kind of merge magic? not sure.

[joefiorini]

Currently I'm using git checkout -p eak/master. That lets me choose
chunk-by-chunk which changes I want to apply, and I can choose to leave my
customizations as well. Takes about 10-15 minutes, but seems like the
easiest way to not lose my changes.

On Thu, Sep 5, 2013 at 10:20 PM, Thomas Boyt [email protected]:

agree on not hiding anything. visible boilerplate > hidden tasks; learned
that from grunt-microlib.

i think upstream strategy is good for now, maybe could add a bit to docs
about it. ember create executable could do something like yeoman, where
it prompts whether you want to overwrite for each changed file. hell, maybe
we could even have it update by using the git repo and doing some kind of
merge magic? not sure.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/24#issuecomment-23915068
.

[ryanflorence]

when the dust settles

• Gruntfile.js will be changing most frequently
• tasks/ will be changing occasionally
• package.json too
• everything else is (should be) a bower or npm dependencies (loom generators, grunt tasks)

so maybe:

1. we check in Gruntfile.js.sample instead of Gruntfile.js
2. ember new clones the repo
3. sets up the upstream branch
4. copies Gruntfile.js.sample to Gruntfile.js

And then users should be able to git pull upstream master with minimal conflicts. Then bower install && npm install and finally decide what they want to bring in from the updated Gruntfile.js.sample.

Also, lets not forget, upgrading pretty much anything is always rough no matter how hard the vendor tries to make it seamless, so its an important goal of EAK to make upgrading easy, but its not the first priority, (maybe second). I think the best strategy is try to make EAK just the aggregate of bower and npm dependencies. Keep our footprint in the repo as small as possible.

[gunn]

@thomasboyt and @rpflorence's ideas sound good to me. I would prefer it though if I didn't have to have my commit history muddled with EAK's though.

I imagine a process like:

npm install app-kit
ember update .
    conflict  Gruntfile.js
Overwrite Gruntfile.js? (enter "h" for help) [Ynaqdh]  
git commit -am 'Updated ember app-kit to 0.2.0.'

One of the options for 'Overwrite Gruntfile.js' could be to copy to Gruntfile.js.sample.

[joefiorini]

@gunn You can avoid muddling the history if you add this repo as a remote (git remote add eak stefanpenner/ember-app-kit) in your codebase and use git read-tree eak/master to pull the code in. To update you can use git checkout --patch eak/master and pick from each change which you want to pull in.

[rwjblue]

@joefiorini - That is way better than what I was doing. Thanks!

[gunn]

@joefiorini great advice! I'll do that for now. I think the official EAK strategy could be more friendly though

[stefanpenner]

closing in favor of: #256