Repository navigation
Document our approach on going to Standard style #70
Description
We are currently converting the code base into Standard style by converting each line that we touch when making changes. This approach is very nice since it doesn't introduce any additional conflicts and makes backporting work well.
However, I've never seen this actually documented somewhere. It would be nice if we could write down what we are doing, and why we are doing it. Maybe in the contributor guide.
We're following the same approach in node-canvas and I would love to be able to link to the description from there 😄
Reacted by Wes Todd
Activity
gireeshpunathil commentedon Mar 25, 2020
@LinusU - mind expanding this for a better context? is it actioned already, and a close-candidate? or if there is anything that needs to be documented, let me know!
LinusU commentedon Mar 25, 2020
I think that the thing left to do is better explain what we are doing, and why we are doing it.
The short explanation is that we're converting each line that we are modifying to Standard style, and the short why is that we are doing it to preserve
git blameand to not cause unnecessary conflicts.As far as actionable things to do, I think that we need to elaborate on this, and then write it down somewhere☺️
jonchurch commentedon Mar 26, 2020
Unrelated to documentation, but a tool similar to https://github.com/grvcoelho/lint-diff could be useful to automate applying standardjs formatting only to lines which are changed.
Similar to but different than the commonly employed https://github.com/okonet/lint-staged which lints an entire file once staged by git add. Or this one,
precise-commitsEdit: Turns out this is not an easily solved problem 🤦♂. If anyone wants to help out on this point, please do. Precise-commits seems the most popular, but it uses prettier under the hood. Prettier has some bugs in its range based formatting which can mess up indenting.