Validate and visualize dependencies. Your rules. JavaScript, TypeScript, CoffeeScript. ES6, CommonJS, AMD.
MIT License
Published by sverweij about 6 years ago
--ts-config
command line parameter that takes a tsconfig and ...
paths
in your tsconfig.json
and dependency-cruiser understands them - see below for an illustration.Thanks to @Bisdow for raising the issue and @ajafff for his deep typescript compiler knowledge + nudges into the right direction in the implementation of this feature.
🐦 dependency-cruiser now is on twitter as well for stuff that doesn't fit issues or PR's: @depcruise
With these sources...
tsconfig.json
src/shared/index.ts
src/index.ts
src/something/else.ts
... this tsconfig.json:
{
"compilerOptions": {
"target": "ES2015",
"module": "commonjs",
"outDir": "./dist",
"baseUrl": "./src",
"paths": {"shared": ["./shared"]},
}
}
... and this command line...
depcruise -T dot --ts-config tsconfig.json src | dot -T svg > tmp_deps.svg
Supporting TypeScript 3.0.0 was little work surprisingly. Thanks to the TypeScript team for keeping the transpiler interface backwards compatible :-)
Published by sverweij over 6 years ago
npm-check-updates
(which appears to be not maintained anymore) with upem
Published by sverweij over 6 years ago
alias
and modules
)
--webpack-config
.dependency-cruiser.json
in a webpackConfig
keypResolveOptions
parameterSee the FAQ
When you add --webpack-config
as a command line option dependency-cruiser will attempt to read the webpack config file passed as argument (or webpack.config.js
in the current working directory if none was passed) and read any resolve
configuration from it.
The latest fashion in webpack configs is to have it return a function that takes up two two parameters (env
and arguments
). If you need those, you can specify them in .dependency-cruiser.json
In the options section you can put a webpackConfig
section that allows for specifying (1) the config file name (2) any environment parameters (3) any other (webpack) command line arguments that might be of interest (all optional). E.g.
...
"options": {
"webpackConfig": {
"fileName": "webpack.config.js",
"env": { "production": true },
"arguments": { "mode": "production" }
}
}
...
or
...
"options": {
"webpackConfig": {
"fileName": "webpack.config.js",
"env": "production",
"arguments": { "mode": "production" }
}
}
...
The cruise
API grew an extra pResolveOptions
parameter that takes a webpack enhanced-resolve resolve key,
resolve
key looks. At the moment it's only possible to pass them in the .dependency-cruiser.json
--env.prod
or --env prod
you'll have to translate as specified in (see environment-options) and put it in .dependency-cruiser.json's webpackConfig section (example below)resolve
key looks, you'll have to pass them in the same manner.webpackConfig
key in the options section that allows for specifying (1) the config file name (2) any environment parameters (3) any other (webpack) command line arguments that might be of interest (all optional). E.g....
"options": {
"webpackConfig": "webpack.config.js",
"env": { "production": true },
"arguments": { "mode": "production" }
}
...
or
...
"options": {
"webpackConfig": "webpack.config.js",
"env": "production",
"arguments": { "mode": "production" }
}
...
--webpack-config
command line parameter that takes a webpack config and uses the resolve
key from it to take into account when resolving stuff. This feature has been tested on a small base of webpack configs and is very thoroughly a beta feature. It's released as beta to ease testing in the wild. Feedback welcome!Mostly technical release with (verified) update of dependencies and some internal code shuffling to make things easier to maintain.
Published by sverweij over 6 years ago
impact classification: very low (and medium if you're using the json output or were hacking on the internal API)
On the top level of the json and bare api object output the array of modules is now called modules
in stead of dependencies
. This is more correct and makes both the json and the code instantly
easier to grasp:
{
"modules": [
{
"source": "src/extract/derive/circular/dependencyEndsUpAtFrom.js",
"dependencies": [],
"valid": true
},
{
"source": "src/extract/derive/circular/index.js",
"dependencies": [
{
"resolved": "src/extract/derive/circular/dependencyEndsUpAtFrom.js",
"coreModule": false,
"followable": true,
"couldNotResolve": false,
"dependencyTypes": [
"local"
],
"module": "./dependencyEndsUpAtFrom",
"moduleSystem": "cjs",
"matchesDoNotFollow": false,
"circular": false,
"valid": true
}
],
"valid": true
},
{
"source": "src/extract/derive/orphan/isOrphan.js",
"dependencies": [],
"valid": true
}
// ... and possibly more modules
],
"summary": {
// stuff
}
}
{
"dependencies": [
{
"source": "src/extract/derive/circular/dependencyEndsUpAtFrom.js",
"dependencies": []
},
{
"source": "src/extract/derive/circular/index.js",
"dependencies": [
{
"resolved": "src/extract/derive/circular/dependencyEndsUpAtFrom.js",
"coreModule": false,
"followable": true,
"couldNotResolve": false,
"dependencyTypes": [
"local"
],
"module": "./dependencyEndsUpAtFrom",
"moduleSystem": "cjs",
"matchesDoNotFollow": false,
"circular": false,
"valid": true
}
]
},
{
"source": "src/extract/derive/orphan/isOrphan.js",
"dependencies": []
}
// ... and possibly more modules
],
"summary": {
// stuff
}
}
impact classification: low (unless you're still on node 4)
Per May 1 node 4 is end of life. While dependency-cruiser would probably keep working under node 4 it was a hassle with all kinds of workarounds. If you want to use dependency-cruiser on node 4 you have two options
(In most cases the best option is to move to a higher version of node)
Root cause: we let the typescript compiler decide whether it was working with .tsx
or .ts
. In some cases it erroneously deduced .tsx
. This transformed some 'typescript-only' dependencies into real javascript ones. With this fix dependency-cruiser takes determining tsx
-iness in its own hand (by looking at the extension).
.tsx
or .ts
. In some cases it erroneously deduced .tsx
, which transformed some 'typescript-only' dependencies into real javascript dependencies. With this fix dependency-cruiser takes determining tsx
-iness in its own hand (by looking at the extension).impact classification: very low (and medium if you're using the json output or were hacking on the internal API)
On the top level of the json and bare api object output the array of modules is now called modules
in stead of dependencies
. This is more correct and makes both the json and the code instantly
easier to grasp:
{
"modules": [
{
"source": "src/extract/derive/circular/dependencyEndsUpAtFrom.js",
"dependencies": [],
"valid": true
},
{
"source": "src/extract/derive/circular/index.js",
"dependencies": [
{
"resolved": "src/extract/derive/circular/dependencyEndsUpAtFrom.js",
"coreModule": false,
"followable": true,
"couldNotResolve": false,
"dependencyTypes": [
"local"
],
"module": "./dependencyEndsUpAtFrom",
"moduleSystem": "cjs",
"matchesDoNotFollow": false,
"circular": false,
"valid": true
}
],
"valid": true
},
{
"source": "src/extract/derive/orphan/isOrphan.js",
"dependencies": [],
"valid": true
}
// ... and possibly more modules
],
"summary": {
// stuff
}
}
{
"dependencies": [
{
"source": "src/extract/derive/circular/dependencyEndsUpAtFrom.js",
"dependencies": []
},
{
"source": "src/extract/derive/circular/index.js",
"dependencies": [
{
"resolved": "src/extract/derive/circular/dependencyEndsUpAtFrom.js",
"coreModule": false,
"followable": true,
"couldNotResolve": false,
"dependencyTypes": [
"local"
],
"module": "./dependencyEndsUpAtFrom",
"moduleSystem": "cjs",
"matchesDoNotFollow": false,
"circular": false,
"valid": true
}
]
},
{
"source": "src/extract/derive/orphan/isOrphan.js",
"dependencies": []
}
// ... and possibly more modules
],
"summary": {
// stuff
}
}
impact classification: low (unless you're still on node 4)
Per May 1 node 4 is end of life. While dependency-cruiser would probably keep working under node 4 it was a hassle with all kinds of workarounds. If you want to use dependency-cruiser on node 4 you have two options
(In most cases the best option is to move to a higher version of node
doNotFollow
in the --init
rule set exclude node_modules on all levels instead of on root only. This makes more sense for monorepos (and doesn't hurt other ones)./
too little.below the water line stuff: