Skip to content
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.

Sign up for GitHub

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

Jump to bottom

mutated array/object declared with const errors but ok with let #691

Closed
rickmed opened this issue Jul 20, 2023 · 7 comments · Fixed by #683
Closed

mutated array/object declared with const errors but ok with let #691

rickmed opened this issue Jul 20, 2023 · 7 comments · Fixed by #683
Labels
Status: Beta Released It's now live. Status: Released It's now live. Type: Feature New features or options.

Comments

@rickmed
Copy link

rickmed commented Jul 20, 2023 •
edited

Suggestion

Is there a setting where, if you declare an array or object with const and mutate it, it errors, but if declared with let it's ok?

I've been searching through the docs but couldn't figure out.

PS: I'm using typescript.
@rickmed rickmed added Status: Triage This issue needs to be triaged. Type: Idea Marks an idea, which might be accepted and implemented. labels Jul 20, 2023
@RebeccaStevens RebeccaStevens added Type: Feature New features or options. Status: Investigation Needed Issue need to be investigated further. and removed Type: Idea Marks an idea, which might be accepted and implemented. Status: Triage This issue needs to be triaged. labels Jul 20, 2023
@RebeccaStevens
Copy link
Collaborator

RebeccaStevens commented Jul 20, 2023 •
edited

No, we don't have an option like that.

What I personally use is the naming-convention rule to enforce variables declared with let are prefixed with m_ (for mutable). Then I use immutable-data's ignoreAccessorPattern to ignore such variables.

I'm not sure if I'd be in favor of adding your suggestion as a built-in option or not. I'd need to think about the flow on effects of such an option.

@rickmed
Copy link
Author

rickmed commented Jul 21, 2023

I think it's worth giving it a good thought.

@rickmed
Copy link
Author

rickmed commented Jul 21, 2023 •
edited

Is there a way to use ignore patterns or something to make all arrays immutable by default but using some regex in the identifier to allow mutations like "let/const mut_arr = []"?

@RebeccaStevens RebeccaStevens removed the Status: Investigation Needed Issue need to be investigated further. label Jul 21, 2023
github-actions bot pushed a commit that referenced this issue Jul 21, 2023
@semantic-release-bot
chore(release): 6.0.0-next.6 [skip ci]
5b1acb9 
# [6.0.0-next.6](v6.0.0-next.5...v6.0.0-next.6) (2023-07-21)

### Features

* **immutable-data:** add new option `ignoreNonConstDeclarations` ([ecde24a](ecde24a)), closes [#691](#691)
@github-actions
Copy link

🎉 This issue has been resolved in version 6.0.0-next.6 🎉

The release is available on:

Your semantic-release bot 📦🚀

@github-actions github-actions bot added the Status: Beta Released It's now live. label Jul 21, 2023
@RebeccaStevens
Copy link
Collaborator

Is there a way to use ignore patterns or something to make all arrays immutable by default but using some regex in the identifier to allow mutations like "let/const mut_arr = []"?

I'm not sure what you mean exactly. ignorePattern will let you match against the variable name (e.g. mut_arr); if it matches then the rule won't report any issues. Any mutations on objects and arrays will be reported so in that sense they are already all immutable by default.

@RebeccaStevens RebeccaStevens mentioned this issue Jul 21, 2023
Merged
@RebeccaStevens

This comment was marked as off-topic.

Sign in to view
@RebeccaStevens RebeccaStevens mentioned this issue Jul 23, 2023
Closed
@rickmed rickmed mentioned this issue Jul 23, 2023
Closed
RebeccaStevens added a commit that referenced this issue Jul 30, 2023
@RebeccaStevens
Merge pull request #683 from eslint-functional/next
103d3a4 
close #599
close #678
fix #467
fix #576
fix #577
fix #611
fix #675
fix #691
fix #692
github-actions bot pushed a commit that referenced this issue Jul 30, 2023
@semantic-release-bot
chore(release): 6.0.0 [skip ci]
27db8bf 
# [6.0.0](v5.0.8...v6.0.0) (2023-07-30)

### Bug Fixes

* add sanity checks to type immutablity override settings ([d3ce5b0](d3ce5b0))
* further updates for v6 ([71ecdb5](71ecdb5))
* **immutable-data:** rework logic, it should work now ([9644994](9644994)), closes [#692](#692)
* migrate code for [@typescript-eslint](https://github.com/typescript-eslint) v6 ([5c6b1a2](5c6b1a2))
* replace `ignorePattern` option with `ignoreIdentifierPattern` and `ignoreCodePattern` ([48d8eba](48d8eba)), closes [#467](#467)

### Build System

* increase minimum supported TypeScript version to 4.3.5 ([aefe6b2](aefe6b2))

### Features

* **functional-parameters:** add option to ignore getters and setters ([9c89b9e](9c89b9e))
* **immutable-data:** add new option `ignoreNonConstDeclarations` ([ecde24a](ecde24a)), closes [#691](#691)
* **no-expression-statements:** add option to ignore self returning functions ([894fb91](894fb91)), closes [#611](#611)
* **prefer-immutable-types:** use suggestions instead of a fixer by default ([#598](#598)) ([3fb9028](3fb9028))
* remove `assumeTypes` option ([6be5862](6be5862))

### BREAKING CHANGES

* replace `ignorePattern` option with `ignoreIdentifierPattern` and `ignoreCodePattern`
* increase minimum supported TypeScript version to 4.3.5
* remove `assumeTypes` option
* **prefer-immutable-types:** The fixer config no longer inherits as many options as before; be sure to be
explicit in your configs.
@github-actions
Copy link

🎉 This issue has been resolved in version 6.0.0 🎉

The release is available on:

Your semantic-release bot 📦🚀

@github-actions github-actions bot added the Status: Released It's now live. label Jul 30, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Status: Beta Released It's now live. Status: Released It's now live. Type: Feature New features or options.
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Next Release eslint-functional/eslint-plugin-functional
2 participants
@rickmed @RebeccaStevens