Infisical/infisical-node

typescript error

Opened this issue ยท 14 comments

uriva commented

getting

This expression is not constructable.
  Type 'typeof import("/home/uri/uriva/my-project/node_modules/infisical-node/lib/index")' has no construct signatures.ts(2351)

for

import { map, pipe } from "gamla";

import InfisicalClient from "infisical-node";

export const getSecrets = (): Promise<Record<string, string>> =>
  new InfisicalClient({ token: process.argv[2] }) // <------------------------------ error is here
    .getAllSecrets({
      environment: "prod",
      path: "/",
    })
    .then(
      pipe(
        map(({ secretName, secretValue }: any) => [secretName, secretValue]),
        Object.fromEntries,
        (secrets: Record<string, string>) => {
          process.env = { ...process.env, ...secrets };
          return secrets;
        },
      ),
    );

This issue has been resolved, please update the package on your end to the latest version and try again

uriva commented

I still see it in version 1.4.3

Until this issue gets fixed you can use the following:

import * as InfisicalClientClass from 'infisical-node';

const client = new (InfisicalClientClass as any)({
  token: 'INFISICAL_TOKEN',
});

same happening to me.
"infisical-node": "1.4.3",

tsconfig:

{
    "compilerOptions": {
        "incremental": true,
        "target": "ES2022",
        "module": "NodeNext",
        "rootDir": "./src",
        "moduleResolution": "NodeNext",
        "allowJs": true,
        "outDir": "./dist",
        "removeComments": true,
        "verbatimModuleSyntax": true,
        "jsx": "preserve",
        "forceConsistentCasingInFileNames": true,
        "strict": true,
        "noImplicitAny": true,
        "experimentalDecorators": true,
        "noUnusedParameters": true,
        "noFallthroughCasesInSwitch": true,
        "emitDecoratorMetadata": true,
        "noImplicitOverride": true,
        "noImplicitThis": true,
        "skipLibCheck": true

        // "esModuleInterop": true
        // "allowSyntheticDefaultImports": true, // To provide backwards compatibility, Node.js allows you to import most CommonJS packages with a default import. This flag tells TypeScript that it's okay to use import on CommonJS modules. auto on with esmoduleinterop
        // "resolveJsonModule": false, // ESM doesn't yet support JSON modules.
        // "moduleDetection": "force"
    },
    "ts-node": {
        // "compilerOptions": {
        //     "module": "CommonJS"
        // },
        "swc": true
    },
    "include": ["src/**/*.ts", "src/**/*.tsx", "src/**/*.js", "src/**/*.jsx"],
    "exclude": ["node_modules", "dist"]
}

Same issue for me in 1.4.3 and 1.5.0 versions

Version 1.5.0 here and I don't get this

1.5.0 still seeing this issue

Hey @uriva ๐Ÿ‘‹

I've just created a test typescript project where it works as intended. Could please share some extra steps on how we can reproduce? It would be great if you could create a mock repository that I can clone on my end!

As @DanielHougaard stated, a re-producible example would be much appreciated.

In case you haven't yet, do try removing your node_modules and lock file to give it a fresh npm i as see if this resolves it also.

tried now and still seeing the issue

I'm on Node.js v21.1.0

reproduction:

{
  "compilerOptions": {
    "module": "NodeNext"
  }
}
{
  "name": "repro",
  "version": "1.0.0",
  "description": "",
  "type": "module",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "author": "",
  "license": "ISC",
  "dependencies": {
    "infisical-node": "^1.5.0"
  }
}
import InfisicalClient from "infisical-node";

console.log(new InfisicalClient({ token: process.env.infisical }));

Reproducible with "module": "NodeNext". Since Infisical node uses commonJS module resolution this explains the compability issue you're seeing.

Are you able to use "module": "commonjs" in your project or is explicity set to NodeNext for a reason?

it's a card at the ground floor of a house of cards

is it replacable? perhaps, but i'm not going to try

i'm using @ts-expect-error

Agreed. This does now identify the isssue however, thanks for raising ๐Ÿ‘