v3.1.1

• 🐛 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

vue that (v3.1.0)

• 🐣 support for vue templates

v3.0.3

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

v3.0.2

• 📖 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

v3.0.1

• ⬆️ acorn, ajv, chalk, commander, eslint, eslint-plugin-mocha, mocha
• 🐥 html reporter: if there's > 1 violation for an incidence, show this in the hint text

consistent awesomeness (v3.0.0)

• symlink handling consistent with node - dependency-cruiser now follows symbolic links, just like node does. Also just like in node, you can override the behaviour (issue #33/ PR #37 - @ajafff)
  a breaking change, but with low or no impact - see below
• package.json lookup consistent with node - dependency-cruiser now uses the package.json closest up to the file being cruised, instead of the one in the directory the cruise was started from. This behaviour is more consistent with how node & npm work, yielding more accurate results and less false positives (issue #35/ PR #38 - @ajafff)
  a breaking change, but with low or no impact - see below
• return all found violations per dependency - instead of only the first one. The internal API and the 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).
• you can set a custom severity for the 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.
• ⬆️ various dependencies and devDependencies
• 📖 various documentation updates

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!

Breaking change: symlink handling consistent with node

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:

• use the --preserve-symlinks command line option
• in the options section of your .dependency-cruiser.json add a preserveSymlinks key with the value true.

Breaking change: package.json lookup consistent with node

impact classification: low

You might see different output from dependency-cruiser in the following cases.

• You have package.jsons in the directory-tree below the directory you're running dependency-cruiser from. This is typical in mono-repos.
  Hence in mon-repos dependency-cruiser will from now on use the package.json you intended in the first place.
• You do not have a 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.

API change: rule object -> rules array of objects

impact 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:

before

{
    "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"
            }
        },
...
    ]
},
...

after

{
    "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"
            }]
        },
...
    ]
},
...

v3.0.0-beta-6

• 🐣 return all found violations on a dependency instead of only one (issue #40 thanks @ajafff again for reporting!, PR #41)
  This goes for both the internal API and the 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.

API change

before

{
    "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"
            }
        },
...
    ]
},
...

after

{
    "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"
            }]
        },
...
    ]
},
...

v3.0.0-beta-5

• feature(validate): return the rule with highest severity if there's > 1 violation per dependency. This is a first step to jus return all rules per dependency
• removes the deprecated --system

v3.0.0-beta-4

• 🐣 Adds an allowedSeverity attribute to the rule set format to so you can set the severity of the allowed rule (which was hitherto fixed to "warn") (issue #34 - thanks @ajafff for the suggestion)

v3.0.0-beta-3

• 🐣 for checking against contents of package.json use the package.json closest to the file being cruised, instead of the one in the directory the cruise was started from. This behaviour is more consistent with how node & npm work, yielding more accurate results and less false positives (issue #35 / PR #38 , both contributed by @ajafff - sehr vielen Dank für diesen Beitrag, Herr Meinhardt!)
  This is a breaking change a.c.t. [email protected]

Breaking change: look up closest package.json

impact classification: low

You might see different output from dependency-cruiser in the following cases.

• You have package.json's in the directory-tree below the directory you're running dependency-cruiser from. This is typical in mono-repos.
  For mono-repos this amounts todependency-cruiser will use the
• You do not have a 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.