[core] Creating a better Conflicter module

[SBoudrias]

What?

Yeoman uses a conflicter system to protect a user's files from unwanted modification.

Every time Yeoman write to a file inside the destination root, the conflict system kicks in an compare the old file with the new file. If there's line deleted, it will prompt the user and ask for resolution (overwrite, skip, display diff, overwrite this one and all next).

This is a very important part of our system because it secure the user and alert him when there's a risk a generator break something.

Issue

The conflicter system is pretty vital to Yeoman, but it is getting old and rusty. In short, it could be made way better!

Feature

The conflicter should be smarter. Right now each time a line is changed, it'll alert the user. For example, minor line changes (syntax) shouldn't display an alert - for example:

 {
   "files": [
-    "bar"
+    "bar",
+    "foo"
   ]
 }

Next on, the conflicter can throw when handling folders. This would be useful to let a user know a generator is going to overwrite a complete directory via a bulk task.

The system also need a good refactoring to keep clean code. And it would be awesome to be able to extract the conflicter in a standalone npm module that could be reused by other projects.

Any else you feel is missing!

Prior art

Find current module here: https://github.com/yeoman/generator/blob/master/lib/util/conflicter.js

Related issues

• Directory bug: https://github.com/yeoman/generator/issues/426
• Extracting in another module issue: https://github.com/yeoman/generator/issues/134 (epic points for closing an issue from 2012!)

[jbnicolai]

@sindresorhus just tipped me on this issue. I'd be more than happy to take a tab at it!

[SBoudrias]

@jbnicolai Still any interest in making this happens? (The system is very bad and start to hurt the kind of iteration we can made around it)

On a general comments, the general current API from the conflict is horrible. We shouldn't use events to communicate back and forth. I feel promises would make sense in this part of the api. Also, the bundling of conflicts make the API pretty weird (#add(), #resolve()), I don't think the conflicter should bother about ordering - consume data and answer.

Also, there's no good reason why the conflicter should handle user interactions. The conflicter should let you know if there's a conflict or not, what's the diff. Then the core system should consume the information, present to the user and take action. (this also mean we might want to make the conflicter sync as it won't need it to handle user interactions)

[sindresorhus]

Agreed. The conflicter should be focused at handling conflicts with good hooks.