-
Notifications
You must be signed in to change notification settings - Fork 888
import-blacklist: support banning the import of specific named exports #3926
import-blacklist: support banning the import of specific named exports #3926
Conversation
1b18d12
to
4fc62ce
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is very cool!
src/rules/importBlacklistRule.ts
Outdated
} | ||
return acc; | ||
}, | ||
{} as BannedImports, // tslint:disable-line no-object-literal-type-assertion |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
.reduce<BannedImports>(...)
should allow you to remove this disable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed
@giladgray Thanks for the review! I've responded to your comments inline. |
1e157ec
to
f8a41a8
Compare
import { difference } from "lodash"; | ||
|
||
import { pull, difference } from "lodash"; | ||
~~~~~~~~~~~~~~~~~~~~ [2] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is there a way to not underline difference
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I assume so, but I really don't think it's worth it — the error message already specifies which is the problematic import.
b98e620
to
d4a390e
Compare
@suchanlee @giladgray Is this good to merge? |
can you merge rebase off of latest master to fix the build? |
d4a390e
to
692c0aa
Compare
@suchanlee Done! |
Any updates on enhancement? |
src/rules/importBlacklistRule.ts
Outdated
@@ -54,9 +88,140 @@ export class Rule extends Lint.Rules.AbstractRule { | |||
} | |||
|
|||
function walk(ctx: Lint.WalkContext<string[]>) { | |||
type Options = Array<string | { [moduleName: string]: string[] }>; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can move Options
out from walk
function and correctly type options
key without casting on line 99.
function walk(ctx: Lint.WalkCONTEXT< Array<string | { [moduleName: string]: string[] }>>) {
src/rules/importBlacklistRule.ts
Outdated
? parentNode.importClause | ||
: undefined; | ||
|
||
const importsDefaultExport = importClause && Boolean(importClause.name); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm wondering whether there are any benefits of doing Boolean(importClause.name)
over simple importClause.name
here and on line 183 if strict-boolean-expressions is disabled?
@ethanbond @suchanlee @giladgray maybe it's worth to add support for custom message why import was blocked (have a look please at similar PR to add support for blocking only specific named exports) |
src/rules/importBlacklistRule.ts
Outdated
// Merge/normalize options. | ||
// E.g., ["a", { "b": ["c"], "d": ["e"] }, "f", { "f": ["g"] }] | ||
// becomes { "a": true, "b": Set(["c"]), "d": Set(["e"]), "f": true }. | ||
const bannedImports = (ctx.options as Options).reduce<BannedImports>( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, it's probably worth for perf reason to move options normalization to the Rule
class above as it's not worth to preprocess options for each file separately.
@desfero Thanks for the feedback!
Yup, that's nicer. I've pushed a fix for this.
I don't know, but I'd rather not disable lint rules if possible. strict-boolean-expressions is sort of a stylistic thing, imo, and if the TSLint team wants it enabled to make sure the variables actually hold a boolean, then I'm fine doing the casting.
I really like this idea. Hopefully, we can get this merged first, though, and then add it. I think it would be as simple as allowing a [
true,
"rxjs",
{ "name": "lodash", "message": "use underscore" },
{ "underscore": [{ "name": "pick", "message": "use x instead" }, "y"] }
]
Makes sense. I'm not sure exactly how the initialization of Rule classes happens, though, or whether it's kosher to add a constructor (which is presumably where I'd compute this), as none of the other Rules seem to define one. Open to input here from the TSLint team. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Rule messages could only mention importing or re-exporting as needed, but not a blocker for merging. ✔
PR checklist
Overview of change:
This extends the existing functionality of
import-blacklist
(without any breaking changes) to make it possible to blacklist imports of specific named exports from a module. The idea is that a module might have some exports that you don't want people to use in your project (even though they're not@deprecated
or@internal
to the module). For example, lodash has apull
method that removes items from an array, mutating the array in place; you may want to ban importing this method, to instead require that people usedifference
, which is likepull
except that it doesn't mutate its argument.Is there anything you'd like reviewers to focus on?
CHANGELOG.md entry:
[new-rule-option] [enhancement]
import-blacklist
: support blacklisting specific named exports