-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fixes 102 #110
Fixes 102 #110
Conversation
Codecov Report
@@ Coverage Diff @@
## master #110 +/- ##
=====================================
Coverage 100% 100%
=====================================
Files 15 15
Lines 338 350 +12
Branches 137 146 +9
=====================================
+ Hits 338 350 +12
Continue to review full report at Codecov.
|
We may want to rename |
Do you have a new name for the option in mind? I guess the best for the users would be if we could keep the old name too for backwards compat. |
I'm not sure what the best name would be. Maybe something like |
As I understand it the option would allow any array method that does not mutate the array? If that is true, perhaps something like Please note that I haven't had the opportunity to use this rule a lot myself yet (my current work project only have read-only-array rule), so I may not be the best judge of how to handle this :-). |
All immutable methods on arrays are allowed by this rule without this option enabled. This option allows mutable methods to be used on arrays as well but only if it is a new array where it is guaranteed that no side-effects will occur as the larger operation is effectively immutable. Example: // Allow the mutable method `fill` to be used directly on a new array.
const foo = new Array(10).fill("hello world"); As to whether this should be the default behaviour, I'm not sure. We might want community feedback on this before doing so. |
Ah, so I misunderstood the purpose of the option, thanks for explaining :-). So the option would allow you to chain a mutation if the previous array method returned a copy. In that case I don't think it should be the default behaviour. IMO all mutation should be disallowed by default. To convey what the option does with a concise name is seems quite hard. Perhaps |
No, that is correct; this option only works on chained methods. |
…chained-mutation-on-new-array'.
I've changed the name of this rule option to If you want to go with another name, just let me know; it's a really quick fix. |
I guess a possible shorter name would be to omit a few words. Maybe something more like |
Well, naming is always hard :-). I agree The shortest I can think of is
|
We could go with |
Yes that is a valid point. I think |
Alright will do. I'll commit the change next time I'm at my computer, should be in an hour or two. Should it be |
Is the old rule name still available as an alias? Otherwise, if we should follow semantic versioning strictly I guess the next release would be 6.0.0 (since we are breaking users with the old rule name). |
The old name is still available as an alias so no need for a major release. |
Nice 👍 I guess this is ready for merge and release then? |
Seems to be :) |
Released in 5.1.0. |
Fixes #102