Cannot use parseFile if the TypeScript compiler moduleResolution is set to bundler

[lowvisiondave]

Is there an existing issue for this?

• I have searched the existing issues

music-metadata version

11.0.0

Current Behavior

TypeScript throw an error when doing the following:

import { parseFile } from "music-metadata";

Because node_modules/music-metadata/lib/core.d.ts does not include a type for parseFile.

Adding // @ts-expect-error allows the application to build successfully, so it seems to just a types issue.

Reproduction repository

Expected Behavior

I would expect the types to match the functions being exported.

Attached audio sample?

• I have provided sufficient information to reproduce the issue

[Borewit]

Thanks for creating a reproduction repository @lowvisiondave !

The problem you are facing is because the node condition, a condition exports, is not correctly set when your project imports music-metadata.

Because node_modules/music-metadata/lib/index.d.ts does not include a type for parseFile.

It certainly does, it is right here:

music-metadata/lib/index.ts

Line 40 in c824bb9

export async function parseFile(filePath: string, options: IOptions = {}): Promise<IAudioMetadata> {

But you are not importing this file, you are importing the compiled version of core.ts, and that does indeed not have parseFile() included.

The reason your conditional export is not working, is most likely related to the fact you are using, "moduleResolution": "bundler", in your tsconfig.json. This module resolution, does not seem to set the node condition, maybe because it is designed for browser usage, I can only speculate why it done like that.

What I fear neither works is this (almost literally taken from TypeScript documentation)

{
  "compilerOptions": {
    "....": "",
    "moduleResolution": "bundler",
    "customConditions": ["node"],
     "....": "",
  }
}

Identical issue on file-type: sindresorhus/file-type#738

I will investigate possible workarounds, to be continued....

[Borewit]

Adding the "customConditions": ["node"] solves the issue, evidence: lowvisiondave/music-metadata-typescript-repro#1

[lowvisiondave]

Interesting, I've never come across that before. Thanks for the explanation!

It might be worth adding a note to the documentation, since I experienced this on a fresh Next.js project and it was discouraging me from using your library.

[net]

Also having this problem. Can this be made to just work out of the box? I've never encountered this issue with any other library before.

[Borewit]

Also having this problem. Can this be made to just work out of the box?

The problem is your TypeScript compiler does not including Node specific functionality, as it believes that if you set the module resolution to bundler , you won't need it.

What do you want me to do about that?

I've never encountered this issue with any other library before.

And which of those libraries have Node.js specific functionality, and nicely integrate browser platforms as well?

Raise the issue where it comes from:

• At Next.js (suggest Next.js to include Node condition by default)
• Support the suggestion that TypeScript should not exclude functions, based on a runtime variable which is not known at compile time: Module resolution: "node" condition does not work when using moduleResolution=bundler microsoft/TypeScript#61357.

[net]

Apologies, that makes sense.

[net]

I wonder if core.ts could include a stub parseFile() whose doc links to this issue and describes the fix for users on Node with moduleResolution set to bundler.

[Borewit]

I wonder if core.ts could include a stub parseFile() whose doc links to this issue and describes the fix for users on Node with moduleResolution set to bundler.

That is a very clever workaround @net.

It is not just not putting in a pointer to the documentation, it is actually sufficient to fool the TypeScript compiler to make it working.

I tested it with Nest.js, by adding to node_modules/music-metadata/lib/core.d.ts :

export declare function parseFile(filePath: string, options?: IOptions): Promise<IAudioMetadata>;

We could implement this in code, and in case it is called runtime we throw an error: "Not loaded with node condition enabled".

[net]

Very nice! Probably should be a maximal descriptive runtime error since it could potentially be seen both by users in a browser runtime and users in a weird TypeScript runtime.

[Borewit]

Very nice! Probably should be a maximal descriptive runtime error since it could potentially be seen both by users in a browser runtime and users in a weird TypeScript runtime.

I agree, and third that parseFile is not designed to parse Web API File, which is also a common misunderstanding.

Can you review? (Written before reading your last suggestion): #2378