Type checking errors when requiring `@hashgraph/sdk`

[acuarica]

Description

When loading the SDK with require('@hashgraph/sdk'), I get a bunch of errors like

node_modules/@hashgraph/sdk/lib/Transfer.d.ts:75:20 - error TS1340: Module 'long' does not refer to a type, but is used as a type here. Did you mean 'typeof import('long')'?

75 export type Long = import("long");
                      ~~~~~~~~~~~~~~

node_modules/long/umd/index.d.ts:1:18 - error TS1479: The current file is a CommonJS module whose imports will produce 'require' calls; however, the referenced file is an ECMAScript module and cannot be imported with 'require'. Consider writing a dynamic 'import("../index.js")' call instead.

1 import Long from "../index.js";

and the error

scripts/create-token.js:21:9 - error TS1479: The current file is a CommonJS module whose imports will produce 'require' calls; however, the referenced file is an ECMAScript module and cannot be imported with 'require'. Consider writing a dynamic 'import("@hashgraph/sdk")' call instead.
  To convert this file to an ECMAScript module, change its file extension to '.mjs', or add the field `"type": "module"` to 'package.json'.

21 require('@hashgraph/sdk');
           ~~~~~~~~~~~~~~~~

Steps to reproduce

In a new npm JavaScript project, add the SDK 2.55.1 and typescript. The package.json's type is left untouched (it's using commonjs as default.

Use the following tsconfig.json

{
    "compilerOptions": {
        "allowJs": true,
        "checkJs": true,
        "module": "Node16",
        "moduleResolution": "Node16",
        "resolveJsonModule": true,
        "noEmit": true,
        "strict": true,
        "exactOptionalPropertyTypes": true,
        "noFallthroughCasesInSwitch": true,
        "noImplicitAny": true,
        "noImplicitOverride": true,
        "noImplicitReturns": true,
        "noImplicitThis": true,
        "noPropertyAccessFromIndexSignature": true,
        "noUnusedLocals": true,
        "noUnusedParameters": true,
    },
}

Then create a minimal script that requires @hashgraph/sdk, for example

require('@hashgraph/sdk');

The errors mentioned above appear when type-checking

npx tsc 

Additional context

If, however, I set skipLibCheck: true in tsconfig.json, I get only the following error mentioned above (errors Module 'long' does not refer to a type disappear)

$ npx tsc
scripts.js:21:9 - error TS1479: The current file is a CommonJS module whose imports will produce 'require' calls; however, the referenced file is an ECMAScript module and cannot be imported with 'require'. Consider writing a dynamic 'import("@hashgraph/sdk")' call instead.
  To convert this file to an ECMAScript module, change its file extension to '.mjs', or add the field `"type": "module"` to 'package.json'.

21 require('@hashgraph/sdk');
           ~~~~~~~~~~~~~~~~

The last version of the SDK is installed

$ npm why @hashgraph/sdk
@hashgraph/sdk@2.55.1 dev
node_modules/@hashgraph/sdk
  dev @hashgraph/sdk@"^2.55.1" from the root project

Hedera network

other

Version

2.55.1

Operating system

macOS

[ivaylonikolov7]

Would you mind checking if the issue is still present with out latest stable version? I think with out latests changes this should be solved.

[acuarica]

Hi @ivaylonikolov7, thanks for the heads up. I've tried it with the latest version 2.59.0. The Module 'long' does not refer to a type error has been solved!

However, the second error still happens

scripts/create-token.js:21:9 - error TS1479: The current file is a CommonJS module whose imports will produce 'require' calls; however, the referenced file is an ECMAScript module and cannot be imported with 'require'. Consider writing a dynamic 'import("@hashgraph/sdk")' call instead.
  To convert this file to an ECMAScript module, change its file extension to '.mjs', or add the field `"type": "module"` to 'package.json'.

21 require('@hashgraph/sdk');
           ~~~~~~~~~~~~~~~~

[acuarica]

The long error still happens with the latest version too (I amended the previous comment). I had the flag skipLibCheck enabled so that's why I didn't see the error before.

[ivaylonikolov7]

Hello there,

Thanks for raising this issue. We've identified the root cause as our project's tsconfig.json configuration. We don't support the moduleResolution and module settings you are using.

The problem stems from our current setting of "moduleResolution": "node", which is now deprecated by Typescript. While we need to update this to a modern value, it could potentially break compatibility for users on older Node.js versions.

We can suggest three options for you:

• Switch to ESM modules: If you use ESM modules in your project, you shouldn't experience these type issues.
• Update your local configuration: As a temporary fix, you can modify your project's tsconfig.json to use "moduleResolution": "node" and "module": "esnext".
• Wait for our next major release: We're currently working on PR feat: update module resolution to node16 #3027 which addresses this and other necessary modernizations. This will be included in our upcoming major version.

Let us know if these solutions work for you or if you need further assistance.

[acuarica]

Hi, thanks for the update and for taking care of this.

Our project needs to be CJS. AFAIU, ESM doesn't play well with Hardhat, and given our project is a Hardhat plugin, we need to keep it CJS.

We also use the package.json's exports field internally. This is to simplify requires within our own tests. We need "moduleResolution" to be at least "node16" so TypeScript is aware of this NodeJS feature.

There is no issue for us to wait for the next major release.