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.

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

camelcase: Option to ignore imports #12527

Closed
kalbert312 opened this issue Nov 4, 2019 · 3 comments · Fixed by #12528, basics/vector#111, basics/vector#113, thinkwee/thinkwee.github.io#39 or alxtford/numconv#46
Assignees
Labels
archived due to age This issue has been archived; please open a new issue for any further discussion enhancement This change enhances an existing feature of ESLint evaluating The team will evaluate this issue to decide whether it meets the criteria for inclusion rule Relates to ESLint's core rules

Comments

@kalbert312
Copy link

What rule do you want to change?
camelcase

Does this change cause the rule to produce more or fewer warnings?
Fewer

How will the change be implemented? (New option, new default behavior, etc.)?

New option: ignoreImports: true/false, default: Debatable. I would say true by default because if the code is in your control, eslint would then only flag the declaration and not where it's imported.
Could possibly accept a string/regexp array to only ignore certain modules.

Existing option: allow (string/regexp array) somehow check these against the module token of an import (ex: import { SomeType } from "react" -> "react") rather than a check on the variable itself. For generated codes/types/etc this will not work well.

Please provide some example code that this change will affect:

import { Some_apolloGenerated_Type } from "./__generated__/graphql-types.ts"; // generated code from apollo codegen

This could be aliased but this code is generated so it's basically futile. Plus it would be hard to come up with aliases for types corresponding to graphql queries/results and their inner types.

What does the rule currently do for this code?
Flags generated types from apollo code gen as violating the rule. These types are dynamically generated based on graphql queries which is the reason for a mix of underscores and camel casing.

What will the rule do after it's changed?
Ignore imports, either selectively or fully.

Are you willing to submit a pull request to implement this change?
No

@kalbert312 kalbert312 added enhancement This change enhances an existing feature of ESLint rule Relates to ESLint's core rules triage An ESLint team member will look at this issue soon labels Nov 4, 2019
@kaicataldo kaicataldo added evaluating The team will evaluate this issue to decide whether it meets the criteria for inclusion and removed triage An ESLint team member will look at this issue soon labels Nov 5, 2019
@kaicataldo
Copy link
Member

I think adding an ignoreImports option similar to ignoreDestructuring makes sense. I don’t think it makes sense to make allow match the module import path - that feels confusing, given how it behaves now.

@g-plane
Copy link
Member

g-plane commented Nov 5, 2019

So, should we treat it as a bug or an enhancement?

@kaicataldo
Copy link
Member

I don't think this is a bug - it looks like everything is working as intended. I believe this is a rule enhancement request.

@g-plane g-plane self-assigned this Nov 6, 2019
ilyavolodin pushed a commit that referenced this issue Nov 10, 2019
* New: add option for camelcase (fixes #12527)

* Docs: add docs about `ignoreImports`

* Chore: add more tests

* Docs: add notice
@eslint-deprecated eslint-deprecated bot locked and limited conversation to collaborators May 10, 2020
@eslint-deprecated eslint-deprecated bot added the archived due to age This issue has been archived; please open a new issue for any further discussion label May 10, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.