.dependency-cruiser.js

/** @type {import('dependency-cruiser').IConfiguration} */
module.exports = {
    forbidden: [
        // {
        //     name: "utils-to-non-utils",
        //     severity: "warn",
        //     comment: "Utils should not depend on non-utils",
        //     from: {
        //         path: "^src/utils",
        //     },
        //     to: {
        //         pathNot: "^src/utils",
        //     }
        // },
        // {
        //     name: "dont-depend-on-vscode-too-much",
        //     severity: "warn",
        //     comment: "Dependencies to vscode should be limited to certain directories",
        //     from: {
        //         path: ["^src/discopop/runners"],
        //     },
        //     to: {
        //         path: "^node_modules/@types/vscode",
        //     },

        // },
        {
            name: 'no-circular',
            severity: 'warn',
            comment:
                'This dependency is part of a circular relationship. You might want to revise ' +
                'your solution (i.e. use dependency inversion, make sure the modules have a single responsibility) ',
            from: {},
            to: {
                circular: true,
            },
        },
        {
            name: 'no-orphans',
            comment:
                "This is an orphan module - it's likely not used (anymore?). Either use it or " +
                "remove it. If it's logical this module is an orphan (i.e. it's a config file), " +
                'add an exception for it in your dependency-cruiser configuration. By default ' +
                'this rule does not scrutinize dot-files (e.g. .eslintrc.js), TypeScript declaration ' +
                'files (.d.ts), tsconfig.json and some of the babel and webpack configs.',
            severity: 'warn',
            from: {
                orphan: true,
                pathNot: [
                    '(^|/)[.][^/]+[.](js|cjs|mjs|ts|json)$', // dot files
                    '[.]d[.]ts$', // TypeScript declaration files
                    '(^|/)tsconfig[.]json$', // TypeScript config
                    '(^|/)(babel|webpack)[.]config[.](js|cjs|mjs|ts|json)$', // other configs
                ],
            },
            to: {},
        },
        {
            name: 'no-deprecated-core',
            comment:
                'A module depends on a node core module that has been deprecated. Find an alternative - these are ' +
                "bound to exist - node doesn't deprecate lightly.",
            severity: 'warn',
            from: {},
            to: {
                dependencyTypes: ['core'],
                path: [
                    '^(v8/tools/codemap)$',
                    '^(v8/tools/consarray)$',
                    '^(v8/tools/csvparser)$',
                    '^(v8/tools/logreader)$',
                    '^(v8/tools/profile_view)$',
                    '^(v8/tools/profile)$',
                    '^(v8/tools/SourceMap)$',
                    '^(v8/tools/splaytree)$',
                    '^(v8/tools/tickprocessor-driver)$',
                    '^(v8/tools/tickprocessor)$',
                    '^(node-inspect/lib/_inspect)$',
                    '^(node-inspect/lib/internal/inspect_client)$',
                    '^(node-inspect/lib/internal/inspect_repl)$',
                    '^(async_hooks)$',
                    '^(punycode)$',
                    '^(domain)$',
                    '^(constants)$',
                    '^(sys)$',
                    '^(_linklist)$',
                    '^(_stream_wrap)$',
                ],
            },
        },
        {
            name: 'not-to-deprecated',
            comment:
                'This module uses a (version of an) npm module that has been deprecated. Either upgrade to a later ' +
                'version of that module, or find an alternative. Deprecated modules are a security risk.',
            severity: 'warn',
            from: {},
            to: {
                dependencyTypes: ['deprecated'],
            },
        },
        {
            name: 'no-non-package-json',
            severity: 'error',
            comment:
                "This module depends on an npm package that isn't in the 'dependencies' section of your package.json. " +
                "That's problematic as the package either (1) won't be available on live (2 - worse) will be " +
                'available on live with an non-guaranteed version. Fix it by adding the package to the dependencies ' +
                'in your package.json.',
            from: {},
            to: {
                dependencyTypes: ['npm-no-pkg', 'npm-unknown'],
            },
        },
        {
            name: 'not-to-unresolvable',
            comment:
                "This module depends on a module that cannot be found ('resolved to disk'). If it's an npm " +
                'module: add it to your package.json. In all other cases you likely already know what to do.',
            severity: 'error',
            from: {},
            to: {
                couldNotResolve: true,
            },
        },
        {
            name: 'no-duplicate-dep-types',
            comment:
                "Likely this module depends on an external ('npm') package that occurs more than once " +
                'in your package.json i.e. bot as a devDependencies and in dependencies. This will cause ' +
                'maintenance problems later on.',
            severity: 'warn',
            from: {},
            to: {
                moreThanOneDependencyType: true,
                // as it's pretty common to have a type import be a type only import
                // _and_ (e.g.) a devDependency - don't consider type-only dependency
                // types for this rule
                dependencyTypesNot: ['type-only'],
            },
        },

        /* rules you might want to tweak for your specific situation: */

        {
            name: 'not-to-spec',
            comment:
                'This module depends on a spec (test) file. The sole responsibility of a spec file is to test code. ' +
                "If there's something in a spec that's of use to other modules, it doesn't have that single " +
                'responsibility anymore. Factor it out into (e.g.) a separate utility/ helper or a mock.',
            severity: 'error',
            from: {},
            to: {
                path: '[.](spec|test)[.](js|mjs|cjs|ts|ls|coffee|litcoffee|coffee[.]md)$',
            },
        },
        {
            name: 'not-to-dev-dep',
            severity: 'error',
            comment:
                "This module depends on an npm package from the 'devDependencies' section of your " +
                'package.json. It looks like something that ships to production, though. To prevent problems ' +
                "with npm packages that aren't there on production declare it (only!) in the 'dependencies'" +
                'section of your package.json. If this module is development only - add it to the ' +
                'from.pathNot re of the not-to-dev-dep rule in the dependency-cruiser configuration',
            from: {
                path: '^(src)',
                pathNot:
                    '[.](spec|test)[.](js|mjs|cjs|ts|ls|coffee|litcoffee|coffee[.]md)$',
            },
            to: {
                dependencyTypes: ['npm-dev'],
                // type only dependencies are not a problem as they don't end up in the
                // production code or are ignored by the runtime.
                dependencyTypesNot: ['type-only'],
                pathNot: ['node_modules/@types/'],
            },
        },
        {
            name: 'optional-deps-used',
            severity: 'info',
            comment:
                'This module depends on an npm package that is declared as an optional dependency ' +
                "in your package.json. As this makes sense in limited situations only, it's flagged here. " +
                "If you're using an optional dependency here by design - add an exception to your" +
                'dependency-cruiser configuration.',
            from: {},
            to: {
                dependencyTypes: ['npm-optional'],
            },
        },
        {
            name: 'peer-deps-used',
            comment:
                'This module depends on an npm package that is declared as a peer dependency ' +
                'in your package.json. This makes sense if your package is e.g. a plugin, but in ' +
                'other cases - maybe not so much. If the use of a peer dependency is intentional ' +
                'add an exception to your dependency-cruiser configuration.',
            severity: 'warn',
            from: {},
            to: {
                dependencyTypes: ['npm-peer'],
            },
        },
    ],
    options: {
        /* Which modules not to follow further when encountered */
        doNotFollow: {
            /* path: an array of regular expressions in strings to match against */
            path: ['node_modules'],
        },

        /* Which modules to exclude */
        exclude: {
            /* path: an array of regular expressions in strings to match against */
            path: [
                'fs',
                'child_process',
                'stream',
                'events',
                'path',
                'node_modules/@types/vscode',
                'utils',
            ],
        },

        /* Which modules to exclusively include (array of regular expressions in strings)
       dependency-cruiser will skip everything not matching this pattern
    */
        // includeOnly : [''],

        /* dependency-cruiser will include modules matching against the focus
       regular expression in its output, as well as their direct neighbours 
       (dependencies and dependents)
    */
        // focus : '',

        /* List of module systems to cruise.
       When left out dependency-cruiser will fall back to the list of _all_
       module systems it knows of. It's the default because it's the safe option
       It might come at a performance penalty, though.
       moduleSystems: ['amd', 'cjs', 'es6', 'tsd']
      
       As in practice only commonjs ('cjs') and ecmascript modules ('es6')
       are widely used, you can limit the moduleSystems to those.
     */

        // moduleSystems: ['cjs', 'es6'],

        /* prefix for links in html and svg output (e.g. 'https://github.com/you/yourrepo/blob/develop/'
       to open it on your online repo or `vscode://file/${process.cwd()}/` to 
       open it in visual studio code),
     */
        // prefix: `vscode://file/${process.cwd()}/`,

        /* false (the default): ignore dependencies that only exist before typescript-to-javascript compilation
       true: also detect dependencies that only exist before typescript-to-javascript compilation
       "specify": for each dependency identify whether it only exists before compilation or also after
     */
        tsPreCompilationDeps: true,

        /* list of extensions to scan that aren't javascript or compile-to-javascript.
       Empty by default. Only put extensions in here that you want to take into
       account that are _not_ parsable.
    */
        // extraExtensionsToScan: [".json", ".jpg", ".png", ".svg", ".webp"],

        /* if true combines the package.jsons found from the module up to the base
       folder the cruise is initiated from. Useful for how (some) mono-repos
       manage dependencies & dependency definitions.
     */
        // combinedDependencies: false,

        /* if true leave symlinks untouched, otherwise use the realpath */
        // preserveSymlinks: false,

        /* TypeScript project file ('tsconfig.json') to use for
       (1) compilation and
       (2) resolution (e.g. with the paths property)

       The (optional) fileName attribute specifies which file to take (relative to
       dependency-cruiser's current working directory). When not provided
       defaults to './tsconfig.json'.
     */
        tsConfig: {
            fileName: 'tsconfig.json',
        },

        /* Webpack configuration to use to get resolve options from.

       The (optional) fileName attribute specifies which file to take (relative
       to dependency-cruiser's current working directory. When not provided defaults
       to './webpack.conf.js'.

       The (optional) `env` and `arguments` attributes contain the parameters to be passed if
       your webpack config is a function and takes them (see webpack documentation
       for details)
     */
        // webpackConfig: {
        //  fileName: 'webpack.config.js',
        //  env: {},
        //  arguments: {}
        // },

        /* Babel config ('.babelrc', '.babelrc.json', '.babelrc.json5', ...) to use
      for compilation (and whatever other naughty things babel plugins do to
      source code).
     */
        // babelConfig: {
        //   fileName: '.babelrc',
        // },

        /* List of strings you have in use in addition to cjs/ es6 requires
       & imports to declare module dependencies. Use this e.g. if you've
       re-declared require, use a require-wrapper or use window.require as
       a hack.
    */
        // exoticRequireStrings: [],

        /* options to pass on to enhanced-resolve, the package dependency-cruiser
       uses to resolve module references to disk. The values below should be
       suitable for most situations

       If you use webpack: you can also set these in webpack.conf.js. The set
       there will override the ones specified here.
     */
        enhancedResolveOptions: {
            /* What to consider as an 'exports' field in package.jsons */
            exportsFields: ['exports'],
            /* List of conditions to check for in the exports field.
         Only works when the 'exportsFields' array is non-empty.
      */
            conditionNames: ['import', 'require', 'node', 'default', 'types'],
            /*
         The extensions, by default are the same as the ones dependency-cruiser
         can access (run `npx depcruise --info` to see which ones that are in
         _your_ environment. If that list is larger than you need you can pass
         the extensions you actually use (e.g. [".js", ".jsx"]). This can speed
         up the most expensive step in dependency cruising (module resolution)
          quite a bit.
       */
            // extensions: [".js", ".jsx", ".ts", ".tsx", ".d.ts"],
            /* What to consider a 'main' field in package.json */
            mainFields: ['main', 'types', 'typings'],
            /*
         A list of alias fields in package.jsons
         See [this specification](https://github.com/defunctzombie/package-browser-field-spec) and
         the [resolve.alias](https://webpack.js.org/configuration/resolve/#resolvealiasfields)
         documentation in the webpack docs. 
         
         Defaults to an empty array (don't use any alias fields).
       */
            // aliasFields: ["browser"],
        },
        reporterOptions: {
            dot: {
                /* pattern of modules that can be consolidated in the detailed
           graphical dependency graph. The default pattern in this configuration
           collapses everything in node_modules to one folder deep so you see
           the external modules, but not the innards your app depends upon.
         */
                collapsePattern: 'node_modules/(@[^/]+/[^/]+|[^/]+)',

                /* Options to tweak the appearance of your graph.See
           https://github.com/sverweij/dependency-cruiser/blob/main/doc/options-reference.md#reporteroptions
           for details and some examples. If you don't specify a theme
           don't worry - dependency-cruiser will fall back to the default one.
        */
                theme: {
                    graph: {
                        /* splines: "ortho" will give you straight lines at the expense of
                                being slow to render on big graphs
                       splines: "true" will give you bezier curves which are faster
                                but might not look as nice
                   */
                        splines: 'true',
                        // ratio: 9/16
                        // rankdir: "TD"
                    },
                    node: {
                        width: 3,
                        height: 0.4,
                    },
                    edge: {
                        arrowhead: 'normal', // https://graphviz.org/docs/attr-types/arrowType/
                        // arrowsize: 1
                    },
                },
            },
            archi: {
                /* pattern of modules that can be consolidated in the high level
          graphical dependency graph. If you use the high level graphical
          dependency graph reporter (`archi`) you probably want to tweak
          this collapsePattern to your situation.
        */
                collapsePattern:
                    '^(packages|src|lib|app|bin|test(s?)|spec(s?))/[^/]+|node_modules/(@[^/]+/[^/]+|[^/]+)',

                /* Options to tweak the appearance of your graph.See
           https://github.com/sverweij/dependency-cruiser/blob/main/doc/options-reference.md#reporteroptions
           for details and some examples. If you don't specify a theme
           for 'archi' dependency-cruiser will use the one specified in the
           dot section above and otherwise use the default one.
         */
                // theme: {
                // },
            },
            text: {
                highlightFocused: true,
            },
        },
    },
}
// generated: dependency-cruiser@16.2.1 on 2024-02-27T19:52:29.796Z