Closed bmarcaur closed 6 years ago
There's just one question: how to add the whitelisted modules to the existing config?
Currently this rule has two config options, so you can write "no-submodule-imports": [true, "dev", "optional"]
without whitelisting dev
or optional
.
Simply adding the whitelisted dependencies after that (or in between) makes the configuration rather confusing.
In addition there is the possiblity of conflict between config options and actual package names.
I think the best approach would be a config object:
"whitespace": [
true,
{
"dev": true,
"optional": true,
"whitelist": ["#", "~"] // property could be named "ignore" as well
]
An aside:
I think @bmarcaur is looking to change the no-implicit-dependencies
rule, not the no-submodule-imports
rule, or the whitespace
rule. You may already know this, but it is unclear to me if we are all on the same page.
My question/suggestion:
Is it possible to allow a config object OR two strings following true
so that it does not break any current configs? So that either of the following would be acceptable:
"no-implicit-dependencies": [
true,
{
"dev": true,
"optional": true,
"allow": ["#", "~", "/app"] // I like "allow" as the exception name, but ditch it if it conflicts with established conventions
}
]
"no-implicit-dependencies": [ true, "dev", "optional" ]
Yeah sorry my example above uses another tslint rule to show an example of what I would want not that I want to change no-submodule-imports
. Sorry that is a bit confusing. Also I imagine that you want to support a heterogeneous API here where it supports both the old and the new format @ajafff to avoid the API break. For example:
"no-implicit-dependencies": [
true,
{
"dev": true,
"optional": true,
"allow": ["#", "~", "/app"] // I like "allow" as the exception name, but ditch it if it conflicts with established conventions
},
"dev",
"optional"
]
edit: I started working on this but then I realized that I broke the API. So unfortunately no real progress to show. Ill take a look at this again when i have time over the holidays.
I just ran into this as well - I have no choice but to disable these rules in my tslint.json.
@viridia: You might consider doing some inline tslint disabling. That way, you'd still get feedback if you accidentally import something that is not in your package file.
That's what I settled on in the meantime. Of course, for my project, I didn't have very many places where I was importing in a way that caused an issue. If you do, it might be a bigger headache.
@happycollision I used absolute imports pervasively throughout the code - based on advice from this medium post: https://spin.atomicobject.com/2017/10/07/absolute-paths-javascript/
I'm also having an issue. This would be so great if we had a fix for this. I ended up disabling the rule in my tslint.json
For those interested have I figured out a very hacky workaround, while we are waiting for a real fix.
Any forecast if that will be implemented?
Need this enhancement too, please consider implement it. :rose:
I would also benefit from this.
I had to disable the no-implicit-dependencies rule because I use absolute imports in my projects. This feature could be very useful.
Need this feature here, too.
this feature would be very much appreciated
https://github.com/palantir/tslint/releases/tag/5.11.0
v5.11.0 [new-rule-option] Add whitelist for no-implicit-dependencies (#3979)
Can documentation be added for this? I don't understand how to use it.
If I have a. devDependencies b. paths listed in tsconfig.json, e.g.
"paths": {
"@App/*": [
"src/*"
],
"@Shared/*": [
"src/Shared/*"
]
},
How would I use this?
I tried:
"no-implicit-dependencies": [true, "dev", ["@App", "@Shared"]],
But I get this error:
/Users/jeremynagel/dev/energylink-project/react-components/data-exporter2/src/DataJunction/DataJunctionTable.tsx
(22,8): Module '@Shared/BootstrapTableFormatters' is not listed as dependency in package.json
Got it working. Here is what I did:
Upgrade to tslint@^5.11.0
In tslint.json
add an array of path's you want to whitelist to no-implicit-dependencies
. In my case I only need to whitelist ~
, so it looks like:
"no-implicit-dependencies": [true, ["~"]]
tsconfig.json
I have the following paths
"paths": {
"~/*": ["./*"]
},
What about dev dependencies @ilearnio ?
@jeznag Hm, not sure if I'll ever need them in my app's code. So far all works good
@jeznag FYI if your paths start with @ then you need to specify the whole name (not just the package name) due to the way the package name is calculated (it seems to not split the name of if itβs starts with an @ symbol): see https://github.com/palantir/tslint/blob/9d7db479596c50bbf89fa87d498ab927763a6eec/src/rules/noImplicitDependenciesRule.ts#L113
Damn! That's a good catch @chris5287 ! I was using the @
to define my local path. I guess i'll start using the ~
from now.
My tslint.json
{
"defaultSeverity": "error",
"extends": ["tslint:latest", "tslint-config-prettier"],
"rules": {
"no-submodule-imports": [true, "~root", "~src"],
"no-implicit-dependencies": [true, ["~root", "~src"]]
},
"linterOptions": {
"exclude": ["node_modules/**/*", "dist/**/*", "test/**/*"]
}
}
My tsconfig.json
{
"compilerOptions": {
"strict": true,
"module": "ESNext",
"moduleResolution": "node",
"target": "ESNext",
"allowSyntheticDefaultImports": true,
"outDir": "dist",
"sourceMap": true,
"baseUrl": ".",
"paths": {
"~root/*": ["./*"],
"~src/*": ["src/*"]
}
}
}
So I can now import local modules without tslint nor ts error.
Eg:
import requestIdMiddleware from '~src/middlewares/request-id';
Don't forget the wildcard (*
) character! Easily missed but critical.
Incorrect:
"paths": {
"path1/": ["dir/"]
}
Correct:
"paths": {
"path1/*": ["dir/*"]
}
π€ Beep boop! π TSLint is deprecated π and you should switch to typescript-eslint! π€
π This issue is being locked to prevent further unnecessary discussions. Thank you! π
Bug Report
TypeScript code being linted
with
tslint.json
configuration:Actual behavior
Expected behavior
I use webpack resolve to support absolute path imports and tslint, on two different linters (no-submodule-imports and no-implicit-dependencies), picks this up as a package import and throws an error. My ask is the ability to configure an ignore for certain import prefixes (or packages in this scenario). Similar to:
I would like to keep the rule enabled as it did help me catch an implicit import but it breaks the above workflow.