Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
New: Revise rule object-property-newline, tests, and docs (refs #6251) #9522
This (1) adds 2 object options to the rule for compatibility with JSCS rule
What is the purpose of this pull request? (put an "X" next to item)
[X] Documentation update
What changes did you make? (Give an overview)
Is there anything you'd like reviewers to focus on?
referenced this pull request
Oct 26, 2017
The 18 conflicts that now appear are the 18 conflicts that appeared earlier, and that I resolved completely. After I did that, the appveyor test is failing and the conflict report has not changed. I do not see any conflict that is new. Thanks for your help, @Aladdin-ADD.
Thanks for the PR!
If I'm understanding correctly, this PR makes multiple changes which are only loosely related:
Would you mind splitting this up into smaller PRs? It's generally easier to discuss and review proposed changes when they're not all bundled into the same PR, because this allows some of the changes to be merged incrementally. If there is disagreement about a particular feature of a large PR, then the entire PR ends up blocked, but if there is disagreement about a feature on one of several smaller PRs, then the other PRs can still get merged while that feature is discussed.
For example, I agree that it might be a good idea to rename the
I don't want to block renaming
When I split this into multiple PRs, it seems that I need to submit them one at a time and wait for each to be approved and merged before submitting the next, if they are interdependent. For example, if we deprecate the existing option name, that deprecated name is still used in some tests, to ensure that the deprecated name is property handled, and some of those tests are tests of new options. So I can’t submit a PR for the new options until I know whether the name-deprecation PR is accepted. So, as a general rule, I should wait to work on anything that depends on a submitted PR until I know the outcome of that PR. Is that a correct understanding, @not-an-aardvark ? Thanks.
My recommendation would be to create each PR from the current state of the
For example, you could create a PR to add new options now, using the