Validate and visualize dependencies. Your rules. JavaScript, TypeScript, CoffeeScript. ES6, CommonJS, AMD.
MIT License
π shasum of the package as published on npmjs: 8ecfe1b82d15ea3bacae4d5a3af20d157d5a79b0
type exports for the other config-utl (babel, webpack, dependency-cruiser) will follow in a separate patch release
π shasum of the package as published on npmjs: b13ef98ddcd2a9ab4c2478526bc010b8420898b7
To keep dependency-cruiser future proof (and sweeter to use) it was necessary to make some breaking changes in v13.
Most of the breaking changes impact only the API/ library. We've worked hard to avoid it, but some affect the CLI as well.
π shasum of the package as published on npmjs: 4ece1a93c4e954f30350cbb99fd62497cb705e51
As dependency-cruiser itself is now written in ESM, it can now also read .dependency-cruiser, babel and webpack configurations in ESM, so you can write them in more modern JavaScript if you want to. Previously supported formats (commonjs, json5 etc) remain supported
In previous versions, even when you had a dependency-cruiser configuration with one of the default names, you still need to pass --config
on the command line to tell it to use that configuration. As of version 13 this is not necessary anymore. Otherwise, the --config
option still work as it did before.
If you want to run the dependency-cruiser CLI without a configuration file you'll have to explicitly pass it --no-config
.
Let me know if you do! I'm interested in these use cases.
This was already possible - in v13, we've made it the default as it proved useful to distinguish dynamic imports from regular ones. See #801 for details.
When I converted dependency-cruiser from commonjs to ESM (on node 19) it turned out dependency-cruiser's self scan took longer than it did before the conversion. Dependency-cruiser's performance-log and closer analysis with node --cpu-prof showed that most of the extra time was added at startup time, importing modules. Because I set myself as a goal to have v13 at least as fast as v12 I took a closer look at what was loaded, that might not be necessary at startup.
I also realized dependency-cruiser's serving 100% from cache scenario hardly needs to run any static analysis code. Lazy loading these modules till after we've established we need them shaves off ~100ms - ~700ms from 100% from cache runs. The 700ms is extreme though - it's because in dependency-cruiser's self scan babel, vue, svelte, typescript, swc and even coffeescript are available at the same time. I pity you if your real live project has this as well...
It is possible to go deeper here and lazy load the individual transpilers as well, making dependency-cruiser's self-scan nice and fast but the gain in practical situations (where you have only one or two of them in place) would be limited, unless there's a transpiler installed you don't use in your setup (but e.g. only have because a devDependency has it - babel is a logical candidate for this). This improvement might come in a future version of dependency-cruiser.
Nodejs 14 is end of life by the end of April 2023 (source). This will mean that most projects will by then have moved to higher versions. If you can't move to nodejs 14 you can keep using dependency-cruiser v12 for a while.
Yarn 1 is still nominally maintained - the yarn team encourages everyone to migrate to yarn 3, which is now maintained for a longer time than yarn 1 ever was. While yarn 1 itself still works fantastically, its pnp implementation won't keep up with new developments in the node landscape (e.g. the node:
prefix doesn't work, ES modules don't work) - they do work in later versions of yarn, so if you're still on yarn 1 with PnP you probably want to upgrade to yarn 3 anyway.
To be clear:
In previous versions, even when you had a dependency-cruiser configuration with one of the default names, you still need to pass --config
on the command line to tell it to use that configuration. This was confusing to many because it's different from most other tools out there in the same space do it.
As of version 13 this is not necessary anymore to pass a --config option to read the default configuration. Otherwise, the --config
option still work as it did before.
If you want to run the dependency-cruiser CLI without a configuration file you'll have to explicitly pass it --no-config
.
Let me know if you do! I'm interested in these use cases.
We've bumped to the most recent version of node-glob which has a breaking change where it doesn't accept \
as path separators anymore - and instead advises to use forward slashes (/
) in stead.
Dependency-cruiser is now implemented in ESM - which means that it can only be called from ESM code anymore. I've been looking for ways to compile it down to commonjs, but the transpiler chains I've tried so far can't (e.g. by refusing to convert top level awaits).
Because in ESM (dynamically) importing modules is an asynchronous affair, all dependency-cruiser interfaces that weren't already had to become asynchronous as well, with the exception of the configuration utility to extract TypeScript configurations.
For an example - see Example to call cruise
.
cruise
signature changeApart from becoming asynchronous, we've rationalised the parameters to cruise
. In the old interface the fourth parameter was reserved to passing a (normalized) TypeScript configuration only, while having no room to pass a babel configuration or any other (future) transpilation configuration.
The new interface makes the fourth parameter an object that can take a tsConfig, a babelConfig, or both of them.
See example to call cruise
below to see how a call could look right now.
cruise
Before:
import { cruise } from 'dependency-cruiser';
import extractDepcruiseConfig from "dependency-cruiser/config-utl/extract-depcruise-config";
import extractTSConfig from "dependency-cruiser/config-utl/extract-ts-config";
import extractWebpackResolveConfig from "dependency-cruiser/config-utl/extract-webpack-resolve-config"
import extractBabelConfig from "dependency-cruiser/config-utl/extract-babel-config";
const lCruiseOptions = {
// ...
};
const lResult = cruise(
["src", "test"],
await extractDepcruiseConfig("./.dependency-cruiser.js"),
extractWebpackResolveConfig("webpack.config.js"),
extractTSConfig("./tsconfig.json"),
// not possible to pass a babel configuration
}
);
After:
import { cruise } from "dependency-cruiser";
import extractDepcruiseConfig from "dependency-cruiser/config-utl/extract-depcruise-config";
import extractTSConfig from "dependency-cruiser/config-utl/extract-ts-config";
import extractWebpackResolveConfig from "dependency-cruiser/config-utl/extract-webpack-resolve-config";
import extractBabelConfig from "dependency-cruiser/config-utl/extract-babel-config";
const lResult = await cruise(
["src", "test"],
await extractDepcruiseConfig("./.dependency-cruiser.js"),
await extractWebpackResolveConfig("webpack.config.js"),
{
tsConfig: extractTSConfig("./tsconfig.json"),
babelConfig: await extractBabelConfig("./babel.conf.json"),
}
);
π shasum of the package as published on npmjs: 1596f4b7cb186ec33388b9d13aeba751935d40e1
π shasum of the package as published on npmjs: 6131ff18b737df25c41bdfdfbfe4eb3610cbf358
See #794
Changes since v13.0.0-beta-5
π― We'll soon be releasing dependency-cruiser v13, which is in beta right now.
Meanwhile here's still a v12 release. Most of the items are back-ports from the v13 beta - it might be a while before v13 is out of beta, and these items will be useful for users of v12 as well.
π shasum of the package as published on npmjs: 99810305b444a94d18dd07550f4e4f84e6366aee
See #794
Changes since v13.0.0-beta-5
See #794.
Additions a.c.t. beta-4:
See #794
a.c.t. the previous beta release this adds two performance improvements + LCM on external dependencies
π sha-sum of the package as published on npmjs: 5ea774872831267c6870dc0d8472455c714ff098
π shasum of the package as published on npmjs: b5fdc3592938c7949c3667ab7758646964732bc4
π shasum of the package as published on npmjs: 3de9c240b9a99c22828544d052cb266ad0c8abbe
π sha-sum of the package as published on npmjs: 407f64aff22a236ca930749899da1c8e1dec0ec0
π shasum of the package as published on npmjs: 688c57f69314c647239c592c7ea72c51948860fe
π shasum of the package as released on npmjs: 3368ee96facf8f3d8cb68dcd821eb63e89dca5c6
π shasum of the package as published on npmjs: d373a31c4d3ab20b40b2dffe9467304281b03932
π shasum of the package as published on npmjs: 01f2e7d573093a354024303d856b4b77395e7052