react-pdf: jpeg-exif: can't resolve 'fs'

Describe the bug

./node_modules/.pnpm/jpeg-exif@1.1.4/node_modules/jpeg-exif/lib/index.js:3:10
Module not found: Can't resolve 'fs'

https://nextjs.org/docs/messages/module-not-found

Import trace for requested module:
./node_modules/.pnpm/@react-pdf+pdfkit@3.1.1/node_modules/@react-pdf/pdfkit/lib/pdfkit.browser.js
./node_modules/.pnpm/@react-pdf+renderer@3.3.0_react@18.2.0/node_modules/@react-pdf/renderer/lib/react-pdf.browser.js
./src/components/core/pdf-viewer.tsx

To Reproduce

// page.tsx

import * as React from 'react';

import { config } from '@/config';
import { PDFViewer } from '@/components/core/pdf-viewer';

export default function Page(): React.JSX.Element {
  return (
    <PDFViewer>
      {/* Document here */}
    </PDFViewer>
  );
}

/// pdf-viewer.tsx

'use client';

import dynamic from 'next/dynamic';
import type ReactPDF from '@react-pdf/renderer';

export const PDFViewer = dynamic<ReactPDF.PDFViewerProps>(
  () => import('@react-pdf/renderer').then((m) => m.PDFViewer),
  {
    ssr: false,
    loading: () => null,
  }
);

Expected behavior I expect it to not use any Node.js functions because if I remove the use client I get this error:

Error: PDFViewer is a web specific API. You're either using this component on Node, or your bundler is not loading react-pdf from the appropriate web build.

Screenshots

Desktop (please complete the following information):

  • OS: MacOS
  • Browser: -
  • React-pdf version: v3.3.0

About this issue

  • Original URL
  • State: closed
  • Created 5 months ago
  • Reactions: 11
  • Comments: 29 (4 by maintainers)

Commits related to this issue

Most upvoted comments

@diegomura can you please create your own fork until they respond to your pull request? We are building a software that is installed by developers using either pnpm, yarn, npm or bun. We cannot have a quick fix to match them all.

if you are using yarn, you can add to your package.json:

  "resolutions": {
    "@react-pdf/image": "2.2.3",
    "@react-pdf/pdfkit": "3.0.4"
  }

it should work as a workaround for the time being

Everybody who’s using this in Next.js app dir will have this issue because the bug was introduced in an internal dependency, not in the renderer package. Even downgrading isn’t an option because it’s a minor version and package managers will install automatically the latest minor (and patch) version of pdfkit.

Agree @ThomasRedstone ! That lib does way more that what it’s used for in here though. So if my PR does not get reviewed in time I might just port the only bit we need to pdfkit (both our fork and the original repo). Can’t be halted forever. As said above I still want to give it a chance

This seems to have been introduced in https://github.com/diegomura/react-pdf/commit/a35b1ba18d293df51293600d8d56015094d222d8

It would be great if you could revert it and not release it in a minor version in the future.

for npm fix

"overrides": {
		"@react-pdf/image": "2.2.3",
		"@react-pdf/pdfkit": "3.0.4"
	},

but yes, we should wait a fix from author

@felipehv gracias por el feedback. Esta libreria la usa pdfkit desde hace ya un tiempo. Si quiero eventualmente usar el proyecto original (lo cual es deseable) tengo que lentamente solucionar las diferencias. El hecho de que no se mantenga desde el 2019 o mucho menos las estrellas que tenga no hace una libreria mejor o peor. En este caso lo importante es simplemente que utiliza una dependencia de Node que no vi al integrarlo

@diegomura no creo que sea buena idea que utilices una librería sin mantenimiento desde 2019, y con 12 estrellas en github, le bajas el nivel a esta tremenda librería que es react-pdf. Lo más razonable en mi opinión es que hagas el fork o agregues el código que uses directamente dentro de la tuya, así no disminuyes la mantenibilidad de react-pdf.

Abrazo

Submitted a change in failing lib https://github.com/zhso/jpeg-exif/pull/36

Hopefully will be included soon, otherwise I might need to fork it or find another solution

This works for me as well! thanks Next.js v14.0.4

This is working for me

	"dependencies": {
		"@react-pdf/renderer": "^3.3.3",
	},
	"pnpm": {
		"overrides": {
			"@react-pdf/image": "2.2.3",
			"@react-pdf/pdfkit": "3.0.4"
		}
	},

Submitted a change in failing lib zhso/jpeg-exif#36

Hopefully will be included soon, otherwise I might need to fork it or find another solution

it has 2y ago last commit and owner has last commit at April, looks like create you own modern version of this will be better solution. Thank you for fast responding!

This is working for me

	"dependencies": {
		"@react-pdf/renderer": "^3.3.3",
	},
	"pnpm": {
		"overrides": {
			"@react-pdf/image": "2.2.3",
			"@react-pdf/pdfkit": "3.0.4"
		}
	},

I had the same issue, using just the webpack fallback without craco worked for me.

Just added this to my nextConfig

  webpack5: true,
  webpack: (config) => {
    config.resolve.fallback = { fs: false, os: false, path: false };
    return config;
  },

Yeah, I was trying to track down the dep that was just recently updated to see if I could find it, but I couldn’t find it. It says the issue is with jpeg-exif, but that package hasn’t been updated in a million years.

Everybody who’s using this in Next.js app dir will have this issue because the bug was introduced in an internal dependency, not in the renderer package. Even downgrading isn’t an option because it’s a minor version and package managers will install automatically the latest minor (and patch) version of pdfkit.

This works with yarn:

"resolutions": {
    "@react-pdf/image": "2.2.3",
    "@react-pdf/pdfkit": "3.0.4",
    "@react-pdf/layout": "3.5.0"
  },

This may work for npm, however I have not personally tested it:

"overrides": {
    "@react-pdf/image": "2.2.3",
    "@react-pdf/pdfkit": "3.0.4",
    "@react-pdf/layout": "3.5.0"
  },

If jpeg-exif is stable there’s absolutely no reason to be jumping to fork it right away.

The fact that it’s had a total of 9 issues in its life, and this is one of them, suggests it’s a tightly scoped package that does a good job (though it’s only recently that the number of installs has jumped up!)

as a work around both yarn@4 and pnpm should be able to provide you a way to override the version of any transient dependancy you feel like you’ve no control over: