Validate and visualize dependencies. Your rules. JavaScript, TypeScript, CoffeeScript. ES6, CommonJS, AMD.
MIT License
Published by sverweij over 6 years ago
Published by sverweij over 6 years ago
err
and json
reporters now have this. The other reporters now show the most severe violation, instead of the first encountered. Could be considered a breaking change -see below for the interface change (issue #40 / PR #41).allowed
rule - if you have the allowed
rule set up, use allowedSeverity
to set a custom severity (issue #34/ PR #39)--system
replaced by --module-systems
--system was already deprecated in favour of the latter.I would like shout out with a big thanks to @ajafff for his excellent issue reports, suggestions and good quality PR's. Without you these features wouldn't have existed!
impact classification: low.
By default dependency-cruiser now follows links when resolving dependencies. This is consistent with how NodeJS behaves itself since version 6.
In the unlikely event you use symlinks (e.g. with npm link/ yarn workspaces) and depend on the old behaviour, you can do one of these:
--preserve-symlinks
command line optionoptions
section of your .dependency-cruiser.json
add a preserveSymlinks
key with the value true
.impact classification: low
You might see different output from dependency-cruiser in the following cases.
package.json
s in the directory-tree below the directory you're running dependency-cruiser from. This is typical in mono-repos.package.json
in the directory you're running dependency-cruiser from.dependency-cruiser
will use the first package.json it finds going up in the directory tree.The different output is more accurate in all cases, so you probably want to use v3.x.x even if your code base fits in one of the above criteria. If not (or if not right now) you can still use v2.x.x for a while.
rule
object -> rules
array of objectsimpact classification: low (and medium if you were hacking on the internal API):
To enable more than one rule violation per dependency to be stored, we renamed the per-dependency rule
to rules
and made them an array of objects, instead of just one object. An example:
{
"source": "node_modules/somemodule/src/somemodule.js",
"dependencies": [
{
"module": "./moar-javascript",
"resolved": "node_modules/somemodule/src/moar-javascript.js",
"moduleSystem": "cjs",
"coreModule": false,
"followable": true,
"valid": false,
"rule": {
"severity": "warn",
"name": "my-cool-rule"
}
},
...
]
},
...
{
"source": "node_modules/somemodule/src/somemodule.js",
"dependencies": [
{
"module": "./moar-javascript",
"resolved": "node_modules/somemodule/src/moar-javascript.js",
"moduleSystem": "cjs",
"coreModule": false,
"followable": true,
"valid": false,
"rules": [{
"severity": "warn",
"name": "my-cool-rule"
},
{
"severity": "error",
"name": "not-in-allowed"
}]
},
...
]
},
...
err
and json
reporters. To accommodate this each 'invalid' dependency's rule
(with only one rule) was replaced with a rules
section with an array of violated rules.{
"source": "node_modules/somemodule/src/somemodule.js",
"dependencies": [
{
"module": "./moar-javascript",
"resolved": "node_modules/somemodule/src/moar-javascript.js",
"moduleSystem": "cjs",
"coreModule": false,
"followable": true,
"valid": false,
"rule": {
"severity": "warn",
"name": "my-cool-rule"
}
},
...
]
},
...
{
"source": "node_modules/somemodule/src/somemodule.js",
"dependencies": [
{
"module": "./moar-javascript",
"resolved": "node_modules/somemodule/src/moar-javascript.js",
"moduleSystem": "cjs",
"coreModule": false,
"followable": true,
"valid": false,
"rules": [{
"severity": "warn",
"name": "my-cool-rule"
},
{
"severity": "error",
"name": "not-in-allowed"
}]
},
...
]
},
...
Published by sverweij over 6 years ago
impact classification: low
You might see different output from dependency-cruiser in the following cases.
package.json
's in the directory-tree below the directory you're running dependency-cruiser from. This is typical in mono-repos.package.json
in the directory you're running dependency-cruiser from.dependency-cruiser
will use the first package.json it finds going up in the directory tree.The different output is more accurate in all cases, so you probably want to use v3.x.x even if your code base fits in one of the above criteria. If not (or if not right now) you can still use v2.x.x for a while.
--preserve-symlinks
option (issue #33, PR #37 thanks @ajafff for the contribution!!)impact classification: low.
By default dependency-cruiser now follows links when resolving dependencies. This is consistent with how NodeJS behaves itself since version 6.
In the unlikely event you use symlinks (e.g. with npm link/ yarn workspaces) and depend on the old behaviour, you can do one of these:
--preserve-symlinks
command line optionoptions
section of your .dependency-cruiser.json
add a preserveSymlinks
key with the value true
.Published by sverweij over 6 years ago
Published by sverweij over 6 years ago
This release partly makes the detection of typescript pre-compilation dependencies (unused imports and types-only imports) an opt-in affair, as this is not always desired.
If you need or want typescript pre-compilation only dependencies to be cruised do one of these:
--ts-pre-compilation-deps
as a command line option"tsPreCompilationDeps": true
in the options section: ...
"options": {
"doNotFollow": "^node_modules",
"tsPreCompilationDeps": true
}
...
Read more in the FAQ and the command line reference.
A side effect of this change is that dependency-cruiser now detects these (typescript) dependencies as well:
🐣 (typescript) detect dependency to imports that aren't used (the typescript compiler throws these out)
🐣 (typescript) detect dependencies in tripple slash directives
⬆️ ajv
semver-try-require
for conditional requires instead of the internal module (d36cfd8, 1f3cb36)Published by sverweij almost 7 years ago