All types are any when using ESM

[danilofuchs]

Is there an existing issue for this?

• I have searched the existing issues

Current behavior

Using inversify 6.1.4 in an ESM project leads to all types being any, as the imports in the .d.ts files do not contain .js extensions:

Adding .js manually fixes the types:

Steps to reproduce

Typescript 5.7.2

tsconfig.json:

{
  "extends": "./node_modules/@tsconfig/node22/tsconfig.json",

  "ts-node": {
    "files": true,
    "transpileOnly": true,
    "esm": true,
    "swc": true,
    "compilerOptions": {
      "module": "Node16",
      "moduleResolution": "Node16"
    }
  },

  "compilerOptions": {
    "lib": ["es2023"],
    "target": "es2022",
    "types": ["reflect-metadata"],
    "experimentalDecorators": true,
    "emitDecoratorMetadata": true,

    "preserveConstEnums": true,

    "noImplicitAny": true,
    "noUncheckedIndexedAccess": true,
    "noImplicitOverride": true,
    "noFallthroughCasesInSwitch": true,

    "useUnknownInCatchVariables": false,

    "outDir": "build",

    "esModuleInterop": true,

    "module": "Node16",
    "moduleResolution": "Node16",

    "baseUrl": ".",
    "paths": {
      "~/*": ["./src/*"],
      "test/*": ["./test/*"]
    }
  }
}

Expected behavior

Types should work correctly

Possible solution

No response

Package version

6.1.4

Node.js version

22.11.0

In which operating systems have you tested?

• macOS
• Windows
• Linux

Stack trace

No response

Other

No response

[notaphplover]

Hey @danilofuchs, please provide a minimum reproduction code via code sandbox or any other platform. A reproduction repository is another valid choice.

Edit: Ok, I just recreated it, on my way to have it a look and fix it
Edit: Ok, I just had a look at the issue, it's not a bug.

Basically, you are using an esm project with a cjs typescript config:

{
  // ...
  "compilerOptions": {
    // ...
    "module": "Node16",
    "moduleResolution": "Node16",
    // ...
  }
}

If you're working on an ESM context you need to have a proper ESM typescript config:

{
  // ...
  "compilerOptions": {
    // ...
    "module": "ES2022",
    "moduleResolution": "Bundler",
    // ...
  }
}

Closing the issue now. If you think this is a typing issue, please provide a recreation code as I asked and I'll reopen the issue.

[notaphplover]

After some consideration (thanks @alecgibson), I double checked docs and realized this is indeed a bug. I should be able to fix this tomorrow. Reopening the issue

[notaphplover]

Hey @danilofuchs, @alecgibson, I just released [email protected] which seems to fix this issue. Could you double check it please? Thanks in advance

[alecgibson]

Sent this on Discord, but also putting here to increase visibility:

Can confirm:

• working in [email protected]
• broken in [email protected] as per the above issue (Binding element 'container' implicitly has an 'any' type.)
• broken differently in [email protected]:

../node_modules/inversify/lib/esm/index.d.ts:350:34 - error TS2315: Type 'ServiceIdentifier' is not generic.

350     getAll<T>(serviceIdentifier: interfaces.ServiceIdentifier<T>): T[];

Where digging into the definitions shows this:

Type alias 'ServiceIdentifier' circularly references itself.ts(2456)

And I notice it's both:

• imported from @inversifyjs/common on line 1; and
• redefined circularly referencing itself with shadowing on line 74 (same with Newable)

I suspect you just need to rename or namespace the import from @inversifyjs/common

[notaphplover]

Hey @alecgibson, [email protected] should solve the issue 😃

[danilofuchs]

I can confirm [email protected] fixes this issue for me!