Transitive dependency on deprecated `uuid@3.x` breaks Electron production builds

[Harukisatoh]

Hey @node-escpos maintainers! 👋

I'm reaching out because I ran into a blocking issue while integrating @node-escpos/core into my Electron application, and I wanted to share what happened and seek for some advice.

What Happened

I'm building an Electron desktop app (using electron-vite + electron-builder), my project already uses uuid@13.0.0 for generating session IDs, and recently added ESC/POS printer support using your awesome library:

pnpm add @node-escpos/core @node-escpos/usb-adapter

Everything worked perfectly in development mode, the printer integration worked great, no errors, smooth sailing.

But then I tried to build for production... and the app completely failed to launch. 🤔

The Problem

After digging through the dependency tree, I found the culprit:

@node-escpos/core@0.6.0
  └── qr-image@3.2.0
      └── (several deps deep...)
          └── request@2.88.2 (deprecated)
              └── uuid@3.4.0

So here's what's happening:

• My app uses uuid@13.0.0 (modern ESM version)
• @node-escpos/core brings in uuid@3.4.0 through old dependencies
• Development works because electron-vite handles the version conflict gracefully
• Production build fails because electron-builder can't package apps with conflicting uuid versions (ESM vs CommonJS exports)

When I ran pnpm why uuid, I saw both versions in my dependency tree, and electron-builder couldn't resolve them during ASAR packaging.

Why I'm Reporting This

I wanted to let you know about this issue because:

1. It's not immediately obvious - The app works in dev, so developers won't catch it until they try to ship
2. It affects Electron users specifically - The combination of electron-builder + ESM modules makes this a blocker
3. The root cause is deprecated dependencies - Specifically request@2.88.2 which was officially deprecated in 2020

If other devs hit this, they might not understand what's happening.

Environment Details

In case it helps with reproduction:

• Package Manager: pnpm 9.x
• Electron: 38.7.2
• Build Setup: electron-vite + electron-builder
• Module System: ESM ("type": "module")
• Node: 22.x
• TypeScript: moduleResolution: "node16"

---

Thanks for maintaining this library! The ESC/POS functionality works great otherwise. Let me know if you need any more details. 🙏

[dosubot]

Hi @Harukisatoh! I'm Dosu and I’m helping the driver team.

You're right about the root cause: the production build failure is due to a transitive dependency chain—@node-escpos/core → qr-image@3.2.0 → request@2.88.2 (deprecated) → uuid@3.4.0 (deprecated, CommonJS)—which conflicts with your project's uuid@13.x ESM usage. This is a known pain point for Electron apps using ESM and electron-builder, as the module system mismatch and duplicate uuid versions break packaging and runtime compatibility.

Currently, the latest @node-escpos/core still depends on qr-image, which brings in these deprecated packages. There are no existing issues, discussions, or roadmap notes in the repo about updating or removing qr-image/request/uuid@3.x, and no official workarounds or overrides have been documented by maintainers or other users (source).

Workarounds you can try:

• If you don't use the QR code features (i.e., don't call printer.qrimage()), you might be able to patch or override qr-image/request/uuid in your build using tools like pnpm.overrides, patch-package, or by aliasing uuid@13.x for all dependencies. However, these approaches can be brittle and may not resolve deep ESM/CJS conflicts.
• For a robust, future-proof solution, replacing qr-image with a modern QR code library (like qrcode, node-qrcode, or qr-encode) would avoid deprecated dependencies and ESM/CJS issues. This would require a code change in @node-escpos/core's Printer class, swapping out qr-image usage for the new library's API (source).

If you need step-by-step guidance on patching, dependency overrides, or want help drafting a migration plan to a new QR code library, let me know!

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.