-
-
Notifications
You must be signed in to change notification settings - Fork 4.8k
Description
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