search

JedWatson / happiness

Standard customised to make me happy
MIT License
124 stars 15 forks source link

fix readme.md about ignoring files #15

Closed bonesoul closed 8 years ago

bonesoul commented 8 years ago

to ignore files, readme mentions this example;

"standard": { "ignore": [ "**/out/", "/lib/select2/", "/lib/ckeditor/", "tmp.js" ] }

where it should be instead "happiness": { "ignore": [ "**/out/", "/lib/select2/", "/lib/ckeditor/", "tmp.js" ] }

quite confusing :)

dcousens commented 8 years ago

@raistlinthewiz make a PR? :)

wesleytodd commented 8 years ago

This readme is basically left untouched to make it easy to merge in new changes from Standard. So anywhere you see standard just replace it with happiness and you should be good.

For reference, I left those because merging the upstream will be a pain in the ass if all those are changed. It will mean a conflict for every one. But I totally agree that it is confusing and would be open to a better solution :)

bonesoul commented 8 years ago

Create a second file like usage.md and document these there or use the wiki?

wesleytodd commented 8 years ago

As this is a fork, I think the goal would be to do as little work as possible to keep up-to-date with the upstream. To me, your solutions sounds like a lot of work. If you are willing to create and maintain that documentation I would be willing to take it on, but otherwise I am on the side of "no thanks". @dcousens opinions?

dcousens commented 8 years ago

ping @Flet, do you manually maintain those aspects for https://github.com/Flet/semistandard/?

bonesoul commented 8 years ago

seems so :)

https://github.com/Flet/semistandard/#ignoring-files

Flet commented 8 years ago

The bulk of upstream changes are all contained in standard-engine socthere is not a lot if sync work to do. Yeah the readme will need to be manually updated :)

The only real sync now is the rules within the eslint shareable configs.

wesleytodd commented 8 years ago

I guess we could take the route of semistandard and just make a whole new readme that we don't merge. I would be happy if someone wanted to PR that :)

wesleytodd commented 8 years ago

Ok, I made a decision on this and just cleared out the readme and updated to only happiness info. In the future when we do updates we will ignore incoming changes to the readme and keep ours. We should add a not to whatever docs we generate for the update process to remember to look through the readme and bring in anything that we like or want to be sure users see. Closing this for whats in #19.