Skip to content

v10.0.0

Compare
Choose a tag to compare
@sverweij sverweij released this 09 May 18:21
v10.0.0
33f13d0

👷‍♀️ maintenance

91e353f build: drop support for node <12.20 (💥 breaking change)

What changed?

From this version on dependency-cruiser supports node ^12.20, ^14 and >=16 (which are not coincidentally the same as the ones nodejs supports).

Why?

  • Dependency-cruiser follows the support schedule of nodejs - which de-supported node 10 this month. Many of its dependencies also stopped supporting it, so it's getting less easy (and safe!) to maintain that situation.
  • Likewise nodejs doesn't support node 13 anymore, and soon won't support node 15 any longer. You can safely upgrade to node 14 and 16 respectively (see the release page on the nodejs website.
  • Node 12.20 contains some useful features earlier versions didn't have, which dependency-cruiser either is already using or will start using in the near future.

What is the impact?

None if you're on node 12.20, ^14 or >= 16 which is likely. Low in all other cases (see How to migrate below)

How to migrate

If you still are on one node 10.x, 13.x or 15.x there's two options:

  • upgrade your node version to a supported version (^12, ^14, ^16 or even ^17 when that comes out)
  • keep using dependency-cruiser@9.26.1

🐛 bugfixes

3fc204d bugfix(validate): correctly filter out dependents from pathNot (#460) (💥 breaking change)

What changed?

This is technically a breaking change: if you had a rule with dependents in them and a pathNot attribute in the from part, the validator would treat the paths in pathNot as if they were regular paths. This is obviously wrong, but if your ruleset relies on this erroneous behaviour rules might fire that didn't before.

Thanks @davidparkagoda who both spotted the error and contributed this bugfix!

Why?

The previous implementation was (quite obviously, in hindsight) wrong.

What is the impact?

None if you're not using dependents rules with a pathNot attribute.

How to migrate

  • If you intended the new behaviour in the first place you now get the correct behaviour.
  • If you did not intend it, but instead put the restriction in a pathNot instead of a path attribute - rename pathNot to path (or merge the things in path and pathNot if a path attribute already existed).