Feature: Master config for Create and Init

[lirbank]

Moving the conversation in issue #82 about custom boilerplate code and default packages for new projects to here.

The idea is to have a customizable global config (and possibly custom boilerplate code) that is used when creating new projects.

Goals

• Change the default behavior of iron to add/remove packages on init/create
• The master config is used to create the project level config on init/create (instead of using the config.json template). If command-line params are provided on init/create then they should be honored.
• (maybe) Custom code added to new projects

Init/create process:

1. If there is no master config, create one
2. copy the master config to the project, honor command-line overrides
3. use the master config to add/remove packages to/from the project

Ref #32

[lirbank]

@cmather @scott-mcpherson would love your comments on https://github.com/lirbank/iron-cli/commit/413a36a4edcd239824bdee6f84ed92480cf8e9b9

I would like to remove these lines too but wanted to hear what you think first, and add iron-router to the default master config instead. I actually think we should remove the '--skip-iron-router' param all together, I mean isn't iron router required? If it's desirable to keep it we should probably make the '--skip-' param universal so it can be used to skip any package in the master config.

[scottmcpherson]

Cool @lirbank. I'll check this out in he morning, but I definitely like the idea.

[cmather]

cool. i would make the master config a template in the lib/templates/config/ folder.

[cmather]

also, can we override opts on the master config at init time?

[lirbank]

@cmather I was hesitant to make the master config a template, since it will only be created the first time (ever) the user is running iron on his/her computer, but I can change that. No problem.

Actually, the regular template config folder will NEVER be used if we have a master config, as the master config will always be used to create new projects. So the difference from now is, instead of copying the config from iron's templates to the project it is copied from ~/.iron/config.json to the project. The idea is the same, but when the config is placed in the users home folder it can by customized. Oh yeah, and I've added the install/remove package option to the config...

I can do it like this:

• The VERY first time a user run iron create the config is copied from the iron template folder to the users home folder. It is then copied from there to the project.
• After that the config is only copied from the user's home folder.

I.e. I could just copy the existing config template, as it will not be used the way it is today. And the <=%%> stuff won't be needed as the initial master config will be hard coded, right?

What do you think?

[cmather]

Making it a template is more for our own maintenance of it. Easier for us to see a template file for something than to have it written in code. Then you can copy the template file to whatever location you wish, filling in data values from a data context. See lib/templates/.iron/config.json for example.

Can we install the master config at ~/.iron/config.json when the iron-meteor package is installed? I think there's a way to run a post install script where we could do this. I think that would be cleaner than the second approach. It might even make sense to create a new iron command where someone can write/override the global config at a later time (post installation of iron-meteor). So they would do, iron config --opt-one='foo' --opt-two='bar'. If the config file already exists, just override the given values. If it doesn't exist, use the lib/template/config/config.json and override using the data context.

[lirbank]

Sure, no problem, I'll use the templates instead

Just making a detour via the user's home folder like this:

1. (first time) copy lib/templates/.iron/config.json to ~/.iron/config.json
2. copy ~/.iron/config.json to currentProject/.iron/config.json

On adding new commands. I thought about it but the reason for config files is to not have to remember command line flags. Creating new meteor projects happens with moderate frequency so nice to have you favorite setup in a personal config file. But I see, you mean editing the config via command line flags. I can do it but isn't it easier to just type $ nano ~/.iron/config.json than figuring out the commands for modifying the config?

Either way, adding the master config without adding a new command is a good start to see how this is working out. I'll start there I think. Ok?

[cmather]

Yeah, modifying the master config with a command line seems silly. Maybe just a command to create the initial default file. And then we can invoke that command on initial installation of the command line tool. I wouldn't add additional state to track the first time a project is created. More difficult to understand and maintain. Instead, I would make it clear that when the npm package is installed we add the .iron/config.json file. Or, at any point in the future you can generate the default config using iron config.

[cmather]

btw copying the default master config to the local project on project create makes sense (assuming it exists, otherwise we'd use the template version from lib/templates/config/config.json).

[lirbank]

Hmm, why do we want a iron config command? I was thinking like this:

On iron create:

1. Check if ~/.iron/config.json exists (master config). If not, copy the master template lib/templates/.iron/config.json to ~/.iron/config.json.
2. We are now sure the master config exists, so just copy ~/.iron/config.json to currentProject/.iron/config.json

That's it! Am I missing something?

[lirbank]

One issue though, how should we handle --coffee flags, etc. on iron create. I would prefer if the master config was not a template (i.e. not a valid JSON file) as I've added remove/add packages to it, and I would like to reference the master config to know which packages to install/delete on create.

We could keep the master config a template (with <%> variables), but then you have to type flags to populate it when creating a new projects, or it will fall back to what is default in the source code of iron. See what I mean? The defaults should be hard coded into the master config, so you don't have to type command line flags and don't have to rely on the defaults in the source code.

[cmather]

It's just a matter of organization/maintainability and usability.

Logic above makes sense, but we should also have the master config installed at the time iron-meteor is installed so that a user can update it before creating a project. Also, at some point, they may want to revert the file back to defaults, or create the file if it's somehow deleted. So having an iron config command makes sense. We could invoke that command on a post install of the iron-meteor cli. So the logic is in one place to create a master config file.

On iron create you can create the .iron/config.json based on ~/.iron/config.json if it exists, or using the npm module template instead. But it doesn't introduce a side effect (create should create a project, not ALSO create other things is the idea).

[lirbank]

We can still allow flags to override the master config on iron create, if desired, but I don't think it the master config should be a template (<%>).

[lirbank]

Aha! Now I understand why we need a iron config command, makes sense!

[ianserlin]

+1 for this feature