dependency-cruiser

• adds a --ts-config command line parameter that takes a tsconfig and ...
  • 🐣passes it on to the typescript transpile step, so you can tell dependency-cruiser how you prefer to compile your code.
  • 🐣 passes it on to the resolution step, so you can use things like paths in your tsconfig.json and dependency-cruiser understands them - see below for an illustration.
• ⬆️ commander, eslint, typescript

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

#57: use a tsconfig in the resolution process

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

before

after

see #57

see #56

• Ensures dependency-cruiser also works with typescript 3.0.0 and up
• 🐛 dependency-cruiser now also works with compiler/ transpiler alpha, beta and rc versions
• ⬆️ semver-try-require and several development dependencies

Supporting TypeScript 3.0.0 was little work surprisingly. Thanks to the TypeScript team for keeping the transpiler interface backwards compatible :-)

• 🐛 be more strict in what to consider (un)followable (see issue #53 and PR #54 for details) - thanks @zakjan for bringing this to attention!

• 🐣 introduces the dependencyType localModule for modules webpack classifies as module, but that are not in a node_modules folder (PR #52, issue #51). Thanks to @BernieSumption for reporting the issue and helping validate the PR.
• ⬆️ eslint, eslint-plugin-mocha
• 🔧 replace npm-check-updates (which appears to be not maintained anymore) with upem

• 🐣 adds support for webpack config resolve support (a.o. alias and modules)
  • on the command line with --webpack-config
  • in the .dependency-cruiser.json in a webpackConfig key
  • in the API as a pResolveOptions parameter
• 🔧 updates several dependencies and development dependencies to latest
• 🔧 removed some files from the npm distribution that weren't necessary on runtime
• 🔧 some internal refactoring to help readability

Webpack config resolve support

Scope

See the FAQ

command line

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 .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" }
    }
  }
...

in the API

The cruise API grew an extra pResolveOptions parameter that takes a webpack enhanced-resolve resolve key,

Some notes on use

• If you normally use environment variables to run webpack (e.g. NODE_ENV=production webpack) you probably should on dependency-cruiser as well if that makes a difference in the resolve section of your config.
• if you normally pass options and parameters to webpack, you probably should pass these on dependendency-cruiser as well - again if that makes a difference on how the resolve key looks. At the moment it's only possible to pass them in the .dependency-cruiser.json
  • If you normally pass things like --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)
  • If you have other parameters that might influence how the resolve key looks, you'll have to pass them in the same manner.

• fix: make sure the passed webpack config file name is written consistently to the cruiser output object.

• 🐥 assign (webpack-) aliased dependencies to the new dependency type aliased. You can also used this dependency type in custom rules.

• 🐛 webpack configurations that return an array, can return an array of object literals, but also an array of functions (or a combination thereof). Dependency-cruiser can now handle those as well.
• 🐥 make scannable extensions overridable by webpack config

• 🐥 adds support for webpack configs that return a function instead of an object literal. In order to accomplish that the dependency-cruiser.json format grew a 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" }
  }
...

• 🐣 adds a --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.

• ⬆️ acorn
• 👷 swap out bithound with code climate (sadly, bithound shut down one or two days ago) for easily publicly verifiable code metrics.
• 🔧 a bunch of refactors in the resolve & extract areas that should make the code easier to maintain. The code climate metrics helped here - as well as cranking up some eslint rules to extra strong.
• ⬆️ few dev dependencies (typescript, coffeescript, eslint-plugin-import, js-makedepend, mocha, nyc, symlink-dir)

• 🐣 introduces orphan detection. See the orphan reference for details. Thanks @adamclerk for suggesting this.
• 🔧 the output json schema changed in a backward incompatible way. If you're using the command line interface this has no impact for you - see below for details.
• 👷 node 4 got de-supported - see below for details.
• 🐛 In some situations dependency-cruiser reported typescript-only dependencies while not explicitly instructed to do so.

Breaking change: json output structure slightly updated

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:

after

{
    "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
    }
}

before

{
    "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
    }
}

Breaking change: node 4 de-support

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

• use [email protected] which is the last version supporting node 4
• send me enough money to make the hassle worth its while.

(In most cases the best option is to move to a higher version of node)

Fix: reporting typescript-only dependencies while not instructed as such

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).

• Same as v4.0.0-beta-1, additionally...
• 🐛 In some situations dependency-cruiser reported typescript-only dependencies while not explicitly instructed to do so. Root cause: we let the typescript compiler decide whether it was working with .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).

• Same as v4.0.0-beta-2, but with some small below-the-waterline refactorings

• 🐣 introduces orphan detection. See the orphan reference for details. Thanks @adamclerk for suggesting this.
• 🔧 the output json schema changed in a backward incompatible way. For typical use (via the command line) this has no impact - see below for details.
• 👷 node 4 de-support - see below for details.

Breaking change: json output structure slightly updated

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:

after

{
    "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
    }
}

before

{
    "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
    }
}

Breaking change: node 4 de-support

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

• use [email protected] which is the last version supporting node 4
• send me enough money to make the hassle worth its while.

(In most cases the best option is to move to a higher version of node

• 🐛 make the 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).
• 🐛 path.join URLs in dot output instead of diy - which fixed a hithereto undetected bug where urls on root level modules might've contained a / too little.
• 🚀 circular dependency checking is a little faster now

below the water line stuff:

• 🔧 various refactoring to make the code simpler/ simpler to navigate
• ⬆️ update various (development) dependencies to latest

• ⬆️ ajv, typescript, coffeescript, eslint-plugin-import, js-makedepend

• 📖 describe which paths dependency-cruiser matches (thanks @jessitron & @ajafff)
• ⬆️ ajv, commander, resolve, eslint, eslint-plugin-mocha, mocha, coffeescript, js-makedepend, nyc
• 🔧 simplify/ reorganise the reporters for easier maintenance