Types not working correctly unless module: "presserve"

[muniter]

Describe the bug Typescript doesn't resolve types correctly unless my tsconfig uses module: Presserve To Reproduce Steps to reproduce the behavior:

1. Use a tsconfig like this:

{
  "compilerOptions": {
    "esModuleInterop": true,
    "skipLibCheck": true,
    "target": "es2022",
    "allowJs": true,
    "resolveJsonModule": true,
    "moduleDetection": "force",
    "isolatedModules": true,
    "verbatimModuleSyntax": true,
    "allowImportingTsExtensions": true,
    "strict": true,
    "noUncheckedIndexedAccess": true,
    "noImplicitOverride": true,
    /* The important option, with module: NodeNext it doesn't work, only with Presserve */
    "module": "NodeNext",
    "outDir": "dist",
    "sourceMap": true,
    "lib": ["es2022"]
  }
}

2. Try the following code:

import type { OnMessageArgs } from "whatsapp-api-js/emitters";

const args = {} as OnMessageArgs;

args.message.type;
//            ^? any

The type of args.message.type is any.

3. If we change the tsconfig compiler option module to Preserve the type is correctly resolved: text | audio | ...

Expected behavior Types should just work, the current tsconfig follows this recommendations

Desktop (please complete the following information):

• OS: mac OS
• Runtime: node 22
• Library Version: 4.0.3, typescript 5.3.3

Additional context Add any other context about the problem here.

[Secreto31126]

Hi,

I just went through the TS documentation to check what module preserve does, and I'm not quite sure if this is the exact reason why the code breaks.

First of all, the preserve option was added in TS 5.4, so it should be throwing an error if you are using TS 5.3 (I guess)

On the other hand, I have an app for black box testing the messages (Secreto31126/whatsapp-api-test), and as you can see, the tsconfig.json file of the project doesn't use preserve (defaults to es6 if not defined, almost identical to NodeNext).

I will definitely go through this issue later today. As you said, the library types should just work, so this is kinda annoying.

Thanks for raising this issue!

[Secreto31126]

PS: I didn't understand what you meant in the Expected Behaviour, is that your tsconfig file or are you recommending using those settings for the library?

[muniter]

PS: I didn't understand what you meant in the Expected Behaviour, is that your tsconfig file or are you recommending using those settings for the library?

That's the tsconfig I'm using in my project.

About the types I was searching for this article that talks about potential issues when dual publishing and how to solve them, and specially that it has a tool that shows which issues a package has I link both in case you find them useful.

[Secreto31126]

Hey, so sorry I took so long to finally get back.

I think 4.1.1 will fix this issue. It wasn't related to the module type, but rather the path resolution in TS and ESM Node, which enforces including a .js at the end of all the imports (even though the code is on TS 🙄)

I will try to implement more testing to prevent such dumb mistakes, as it's clear v4 was a catastrophic release due to the lack of code quality I usually try to give. I will also check out tsup, which is the tool mentioned on the article you sent.

Please, let me know if this solves the issue so I can safely close it, and once again so sorry to have left you on hold for almost a month.