node: prefix error using in browser

[AaronPorts]

Get the following errors when I try to use fileTypeFromBlob in browser:

ERROR in node:buffer
Module build failed: UnhandledSchemeError: Reading from "node:buffer" is not handled by plugins (Unhandled scheme).
Webpack supports "data:" and "file:" URIs by default.
You may need an additional plugin to handle "node:" URIs.
...

ERROR in node:stream
Module build failed: UnhandledSchemeError: Reading from "node:stream" is not handled by plugins (Unhandled scheme).
Webpack supports "data:" and "file:" URIs by default.
You may need an additional plugin to handle "node:" URIs.
...

I can successfully build my project only with target: "node" in webpack config. Webpack 5.64.4, file-type 17.0.0.

[daveteu]

I think version 17 is broken for browser (at least), or server side rendering.

[pastelmind]

I ran into a similar issue using Vite.js and ended up using magic-bytes.js instead. It's much smaller and doesn't rely on the Node.js stdlib.

[Borewit]

Thank you for bringing this issue to our attention.

It is clear that ES-Module introduced some issues using file-type in the browser. Although file-type has been primarily written for Node.js, I would personally like to see it can be easily used by the client side community as well.

One of the aims of ES-Module is improving interoperability, and here we are, it seems now harder then every before.

The dependency on node:Buffer seems to be the challenge. You client side boys and girls always fixed that by polyfilling Node with Webpack.

That pollyfilling seems to slowly move to the trashcan, just like CommonJs modules. Modules must specify there own requirement and not rely on pollyfills. I believe what is missing is that file-type does not declare a dependency on node:Buffer. At the same time, for a Node environment, our primary audience, it is not really great to introduce dependencies already overlapping with the Node.js API.
It would be great if we could depend on buffer only in a browser environment. Similar how we only fileTypeFromFile(path) expose to Node.

I have no magical solution here, I am not super experienced with ES-module, maybe there is a very simple solution. It's an open source project, everyone could pick up this challenge.

Looking forward to hear your thoughts.

[AaronPorts]

@Borewit thanks for your reply. As a workaround, we can install polyfills and import them by webpack directly:
npm install buffer readable-stream -S
in webpack plugins section:

new webpack.NormalModuleReplacementPlugin(/node:/, (resource) => {
  const mod = resource.request.replace(/^node:/, "");
  switch (mod) {
    case "buffer":
      resource.request = "buffer";
      break;
    case "stream":
      resource.request = "readable-stream";
      break;
    default:
      throw new Error(`Not found ${mod}`);
  }
}),

But I've got another problem in strtok3 package as it uses Buffer without import. For example when file-type use tokenizer.readToken it results in an error.

[Borewit]

Thanks for sharing your solution @AaronPorts, that looks like a very reasonable solution to me.

I have released strtok3@v7.0.0-alpha.5, which got explicit Buffer imports.

If you reinstall file-type dependency, is the strtok3 import issue resolved?

[AaronPorts]

@Borewit I tried alpha.5 version but have module has no exports errors. Probably this is because of CommonJS output instead of ES2020 in TypeScript.

[Borewit]

@Borewit I tried alpha.5 version but have module has no exports errors. Probably this is because of CommonJS output instead of ES2020 in TypeScript.

You are right, forgot to compile code before publishing, another attempt: 7.0.0-alpha.6

[AaronPorts]

I've just checked, strtok3 7.0.0-alpha.6 seems good, but the same issue with Buffer import in token-types 4.1.1

[Borewit]

I've just checked, strtok3 7.0.0-alpha.6 seems good, but the same issue with Buffer import in token-types 4.1.1

Sorry for my late reply. token-types is no ES module yet, and id does not like if I create an explicit import to 'node:Buffer'.
I did create myself a little task to make it en ES-module: Borewit/token-types#389

[Borewit]

@AaronPorts can you let us know if your issue is now resolved?

[AaronPorts]

@Borewit It seems that token-types 5.0.0-alpha.1 has wrong exports Borewit/token-types#393 (comment)

[Borewit]

@Borewit It seems that token-types 5.0.0-alpha.1 has wrong exports Borewit/token-types#393 (comment)

Missed that one, created Borewit/token-types#396, PR Borewit/token-types#397, fixed in v5.0.0-alpha.2.

[Borewit]

Can this one be closed now @AaronPorts ?

[AaronPorts]

Sorry for the delay, seems good for me.

[Majnuel]

i installed axios as a dependency and this started happening, no idea how to solve it

[lawloretienne]

Is there a solution for this issue. Seems like it's still broken.

i tried one of the code snippets from the readme.

The stream method can also be used to read from a remote location:

import got from 'got';
import {fileTypeFromStream} from 'file-type';

const url = 'https://upload.wikimedia.org/wikipedia/en/a/a9/Example.jpg';

const stream = got.stream(url);

console.log(await fileTypeFromStream(stream));
//=> {ext: 'jpg', mime: 'image/jpeg'}

but looks like its an issue with the imports.

Is there a fix for this?

[Alex37882388]

I modified it to support browsers based on this repo, I hope it can help you:
https://www.npmjs.com/package/file-type-browser

[EurekaChen]

I modified it to support browsers based on this repo, I hope it can help you: https://www.npmjs.com/package/file-type-browser

but how to use？ can you give a example?

[italoiz]

I faced this issue when building my Next.JS application, which uses version 14.0.0. And I put 'use server'; at the top level of the file, and I could build the application.

Example

'use server'; // <<< --- this does the trick

// ... rest of the file

[GustavoOS]

I have the same problem when using a Next (14.2.3) component with dynamic import

[alextorn]

Still doesn't work in browsers, when using inside nextjs client components