Refactor Generators about generator

[peol]

+1 for option 2. If they do run yeoman init in a non-empty folder, we might as well just assume that they want to control what files should be overwritten as well. The only issue I see with this is that incompatibilities might occur, but I guess we can't blame yeoman for that - I'm just worried that the issues sections might have an increase in PEBKAC issues like these.

[addyosmani]

Looking through our generators, it would appear that all of them will require warnOn if we want to prompt people about replacing files. I can add this in today.

One limitation of this at present is that it will blanket warn on the replacement of all files or files of a specific type, but doesn't allow users to confirm which files get overwritten and which ones don't in a prompt form. e.g

Confirm: 'index.html' is about to be overwritten. Proceed? y/n
Confirm: 'main.js' is about to be overwritten. Proceed? y/n

The present behaviour instead will be that we warn before overwriting once and require you to pass the --force flag if you wish to proceed.

@mklabs do you have any suggestions for how we might improve the experience by hooking into the prompts API? Ideally if we could get back a list of what is being overwritten that would be useful. I think you mentioned a _warns array earlier on in our discussions :)

[mklabs]

I really like how this problem is handled in Rails generators. I definitely think we should try to implement something similar.

They have a nice file collision menu (actually coming from Thor API: https://github.com/wycats/thor/blob/master/lib/thor/shell/basic.rb#L221)

$ rails g assets foo
      invoke  coffee
   identical    app/assets/javascripts/foo.js.coffee
      invoke  scss
   identical    app/assets/stylesheets/foo.css.scss

$ # do some changes to foo.css.scss
$ rails g assets foo
      invoke  coffee
   identical    app/assets/javascripts/foo.js.coffee
      invoke  scss
    conflict    app/assets/stylesheets/foo.css.scss
  Overwrite /Users/mk/test/rails/foo/app/assets/stylesheets/foo.css.scss? (enter "h" for help) [Ynaqdh] h
  Y - yes, overwrite
n - no, do not overwrite
a - all, overwrite this and all others
q - quit, abort
d - diff, show the differences between the old and the new
h - help, show this help
  Overwrite /Users/mk/test/rails/foo/app/assets/stylesheets/foo.css.scss? (enter "h" for help) [Ynaqdh] Y
       force    app/assets/stylesheets/foo.css.scss

Basically, whenever a file is written and that a collision is detected, this file collision menu pops out with all these options. The differences output is also pretty handy.

[addyosmani]

I like that. It provides pretty much flexibility for what I imagine are most developers expectations for overwrite/collision. Is there a way that we could build on top of warnOn to achieve something similar?

[mklabs]

If we introduce this API, warnOn might become obsolete. I don't know.

This file menu would be tied to the file system API provided in the generators API (write, copy, template methods etc.). And would show up only when we detect that a file is about to be overwritten and that this file is not identical.

We might be able to implement the differences output by checking out how it's done within mocha, it has a really nice diff feature.

[addyosmani]

As we aren't on version 1.0 yet, I don't mind us deprecating warnOn at some point if we're able to come up with something more robust. Do you imagine the API proposed would take a lot of effort? (just trying to balance the solutions we're discussing in email vs a more long-term sustainable option)

[mklabs]

https://github.com/visionmedia/mocha/blob/master/lib/reporters/base.js#L318-352 :) (for future references if we want to provide the same diff output)

It's not trivial for sure, but I don't feel it's that difficult to implement, or at least take a try and see how it goes.

Complexity relies in being able to catch any file writes that might happen, this include overwrites that might be done using the remote API, or full directory copy.

[addyosmani]

Thats pretty sexy! Glad to hear that you don't feel a better API would be overly difficult to implement.

As we've had quite a few developers asking about generator overwrites recently, I wouldn't mind us just landing something slightly better using either the current warnOn updates (or something similar to the path-specific notices we discussed) for 0.9.1 with a view to a much better file API coming in a future 0.9.x release.

[addyosmani]

We've now got 7a7dbc6 which is the first step towards solving the issues discussed. These will be going into 0.9.1, which we'll be releasing on Friday.

[sindresorhus]

@mklabs I really like your suggested solution. Sounds like a super solid one if done right. Lets do it after 1.0!