dependency-cruiser

• 🐣 support for vue templates

• ⬆️ 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

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

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

• 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

• 🐣 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)

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

• 🐣 by default follow symlinks / add --preserve-symlinks option (issue #33, PR #37 thanks @ajafff for the contribution!!)
• ⬆️ devDependencies: coffeescript, eslint, eslint-plugin-import

Breaking change: symbolic links followed by default

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.

• 🐣 introduce globs as command line arguments so globbing can be used cross platform (issue #32, PR #36); thanks @ajafff for the suggestion!

• 🐥 run 'glob' on passed arguments to abstract file expansion mechanism across platforms (issue #32, PR #36)

• ⬆️ acorn, chalk, commander, lodash, semver-try-require
• ⬆️ coffeescript, typescript
  (This verifies dependency-cruiser also works with latest versions of coffeescript (2.2.1) and typescript (2.7.2))
• ⬆️ development dependencies eslint, eslint-plugin-node js-makedepend, mocha and nsp

• 🐣 (typescript): add a command line switch to opt in to typescript pre-compilation dependencies (#31)
• 🐛 (typescript): make typescript (pre-compilation) dependency detection compiler version independent
• ⬆️ ajv, typescript

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:

• pass --ts-pre-compilation-deps as a command line option
• if you have a .dependency-cruiser.json, put "tsPreCompilationDeps": true in the options section:

    ...
    "options": {
        "doNotFollow": "^node_modules",
        "tsPreCompilationDeps": true
    }
    ...

Read more in the FAQ and the command line reference.

• 🐣 (typescript): add a command line switch to opt in to typescript pre-compilation dependencies
• 🐛 (typescript): make typescript (pre-compilation) dependency detection compiler version independent
• ⬆️ ajv, typescript

• 🐛 (typescript) leave 'import equals' without a 'require' (but instead a variable of some sort)

• 🐣 (typescript) also detect dependencies when only importing types. Fixes #28. The two next features are a side effect of this change:
• 🐣 (typescript) detect dependency to imports that aren't used (the typescript compiler throws these out)
• 🐣 (typescript) detect dependencies in tripple slash directives
• 🔧 some refactoring for better performance and easier maintenance
• ⬆️ ajv

• 🔧 some refactoring for better performance and easier maintenance

• 🐣 (typescript) also detect dependencies when only importing types. Fixes #28.

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

• 🐛 corrects a typo in the 'initial' rules that prevented spec files to be detected correctly (86cb294)
• 🔧 (api): make the typescript type definitions tslint 'recommended' compliant (6dc254e, cef02d1)
• 🔧 use semver-try-require for conditional requires instead of the internal module (d36cfd8, 1f3cb36)
• 🏗 publish less to npm (8552028, b00bd38)
• ⬆️ eslint, js-makedepend (6095fae, eb3d3ad)
• 👷 optimise ci use (644400c, bc8440b)

• 🐣 make dependency-cruiser rules work consistently across msdos and posix based platforms
• 👷 add appveyor as ci to ensure non-regression on msdos based platforms
• ⬆️ ajv, commander, semver (, mocha, eslint)

• 🐣 make dependency-cruiser rules work consistently across msdos and posix based platforms
• 👷 add appveyor as ci to ensure non-regression on msdos based platforms
• ⬆️ ajv, commander