Feature request: ts compiler option `moduleSuffixes`

[sipris]

Dependency Cruiser seems not to support the moduleSuffixes typescript compiler option.

Context

I generate some ts files, this files get a suffixes, e.g., some-module.gen.ts. I use the respective ts option so that I can import such files like this: import * from 'some-module';

Expected Behavior

I'd expect Dependency Cruiser to respect this ts compiler option and resolve the module paths accordingly.

Current Behavior

Dependency Cruiser marks such files as an "unknown" dependency type and is not able to resole them.

[sverweij]

Hi @sipris thanks for raising this issue. I somehow completely missed this addition to the ever growing Gödel set of options to resolve modules to disk. Either tsconfig-paths (which dependency-cruiser uses under the hood) missed them as well, or we're holding it wrong :-).

If I understand typescript documentation on moduleSuffixes correctly putting ["gen", ""] as values will instruct the resolver to look for some-module.gen.ts and if not found for some-module.ts. This looks straightforward, so straightforward I can suggest a workaround (see below).

However I have some worries as well for implemtation. That .ts extension is one of a range of an import in typescript can resolve to; others include e.g. .mts, .cts, .tsx, mtsx, ctsx, .js, .mjs, .cjs, .jsx. If that's indeed the case resolution might become slow (3 suffixes x 9 extensions => worst case scenario 27 file look ups per dependency) and/ or interesting. Give me a bit to do some research & meditate on that ...

A potential workaround

In the .dependency-cruiser.js configuration it's possible to pass the extensions to resolve to to the resolver. Adding the suffixes + extensions to that array should ensure resolution:

// ...
options: {
   // ...
   enhancedResolveOptions: {
      extensions: [
        ".gen.ts",
        ".ts",
        // You'll need these guys for e.g. stuff resolved within node_modules
        ".cjs",
        ".mjs",
        ".js",
        // ".jsx",
        // ".ts",
        // ".cts",
        // ".mts",
        // ".tsx",
        ".d.ts",
        // ".d.cts",
        ".d.mts",
      ],
    },
  // ...
};

To prevent having to keep this in sync with tsconfig.json it's also possible to read it from there directly e.g. (note: untested code):

const tsConfig = require("./tsconfig.json");
// ... or use one of the funky construct necessary in ESM to read from json files

const moduleSuffixes = tsConfig?.compilerOptions?.moduleSuffixes ?? [];
// edit: a previous version omitted the . before the suffix; but we _do_ need it
const extensionsWithSuffixes = moduleSuffixes.map(suffix => `.${suffix}.ts`);

// ...
options: {
   // ...
   enhancedResolveOptions: {
      extensions: [
        ...extensionsWithSuffixes,
        ".cjs",
        ".mjs",
        ".js",
        // ".jsx",
        // ".ts",
        // ".cts",
        // ".mts",
        // ".tsx",
        ".d.ts",
        // ".d.cts",
        ".d.mts",
      ],
    },
  // ...
};

When dependency-cruiser grows support for moduleSuffixes it'll do something like this under the hood.

[sipris]

Hi @sverweij, thank you for the quick response.

I'm not sure if I got your workaround right. So I'll try to summarize your idea first:
By adding .gen.ts to the extensions field dependency-cruiser should be able to grep .gen.ts files when traversing directories and then the resolution should work.

If this was the proposal, than unfortunately, it is not quite what I was looking for. Actually, dependency-cruiser catches the *.gen.ts files. However, when it finds some import, let say import * from 'some-module'; it does not understand that it is actually some-module.gen.ts.

Here is an excerpt from the json created by dependency-cruiser of a dummy project:

    {
      "source": "src/folder-1/module-gb.js",
      "dependencies": [
        {
          "module": "fd2/module-gc",
          "moduleSystem": "es6",
          "dynamic": false,
          "exoticallyRequired": false,
          "dependencyTypes": [
            "unknown"
          ],
          "resolved": "fd2/module-gc",
          "coreModule": false,
          "followable": false,
          "couldNotResolve": true,
          "matchesDoNotFollow": false,
          "circular": false,
          "valid": true
        },
        {
          "module": "fd2/module-gd",
          "moduleSystem": "es6",
          "dynamic": false,
          "exoticallyRequired": false,
          "dependencyTypes": [
            "undetermined",
            "import"
          ],
          "resolved": "src/folder-2/module-gd.js",
          "coreModule": false,
          "followable": true,
          "couldNotResolve": false,
          "matchesDoNotFollow": false,
          "circular": false,
          "valid": true
        }
      ],
      "valid": true
    },
    {
      "source": "fd2/module-gc",
      "followable": false,
      "coreModule": false,
      "couldNotResolve": true,
      "matchesDoNotFollow": false,
      "dependencyTypes": [
        "unknown"
      ],
      "dependencies": [],
      "valid": true
    },
    {
      "source": "src/folder-2/module-gc.gen.js",
      "dependencies": [
        {
          "module": "./target-module",
          "moduleSystem": "es6",
          "dynamic": false,
          "exoticallyRequired": false,
          "dependencyTypes": [
            "local",
            "import"
          ],
          "resolved": "src/folder-2/target-module.js",

As you can see, dependency-cruiser finds the source "source": "src/folder-2/module-gc.gen.js",. But the resolution path of "module": "fd2/module-gc" for source "src/folder-1/module-gb.js" is just "resolved": "fd2/module-gc",.

Note: In this dummy project I'm testing various approach for some actual project. fd2 is a ts alias for src/folder-2 and it works correctly. So this has no effect on the issue described above :)

For now, as a workaround I'll append .gen to the concerning imports in the actual project.

[sverweij]

Hi @sipris thanks for checking.

From the short output snippet it looks like the module resolution indeed doesn't work.

• You see the .gen.ts/ .gen.js in the list of modules - this is because dependency-cruiser first gathers all files in de glob-pattern you feed it, and my guess the .gen.ts/ .gen.js files were part of that.
• None of the .gen.xx files show themselves any of the modules' dependencies, though. Dependencies appear when dependency-cruiser looks at a module, runs through all of its imports c.s. and tries to resolve them to disk. The extensions is the array of extensions it (or rather enhanced-resolve) tries when resolving. Apparently this does not work as expected, and I'm curious to find out why.

Can you share the dummy project? A minimal reproduction repository like that will shorten research tremendously (I tried to set up one yesterday evening, but even tsc wasn't able to find the .gen.ts there, so I did something wrong ...)

[sipris]

Sure, sorry, I should've done that from the start.
You'll also find an SVG in the project root that illustrates the project structure.
Looking forward to what you'll find out :) Thanks!

depcruiser-experiments.zip

[sverweij]

Thanks @sipris - my private life was a sort of roller coaster the past weeks, so I haven't been able to have a look yet. But just so you know - I haven't forgotten you!

[sipris]

Same here 🙂 Thanks for the update — wishing you all the best! 👍

[sverweij]

Thanks @sipris - same for you.

With the help of your reproduction example (thanks!) I found the (embarassingly simple) root cause of the issue why the workaround didn't work in all cases (aliased -> works, in extension array -> works, aliased + in extensions array -> doesn't work) and have a fix. After that is merged to main I'll start using it to moduleSuffixes support.

[sipris]

Thanks! That’s fantastic news 🙂