Skip to content

feat: add Windows ARM64 (aarch64-pc-windows-msvc) native build #205

Open

Description

@SEUboyChan2023

Summary

Windows ARM64 users cannot load @firecrawl/anydoc at all — no native binding is published for aarch64-pc-windows-msvc.

Environment

  • Windows 11 ARM64 (Snapdragon 8cx Gen 3)
  • Node.js 22.23.3, process.arch === "arm64"
  • @firecrawl/[email protected]

What happens

require("@firecrawl/anydoc") throws:

Cannot find native binding. npm has a bug related to optional dependencies (https://github.com/npm/cli/issues/4828). Please try `npm i` again after removing both package-lock.json and node_modules directory.

Why

  • package.json napi.targets includes x86_64-pc-windows-msvc but not aarch64-pc-windows-msvc, and optionalDependencies has no @firecrawl/anydoc-win32-arm64-msvc.
  • The generated index.js already contains the win32/arm64 branch (require("@firecrawl/anydoc-win32-arm64-msvc")), so only the published artifact is missing.
  • https://registry.npmjs.org/@firecrawl/anydoc-win32-arm64-msvc returns 404 for every version.
  • The v0.2.4 GitHub release attaches anydoc.win32-x64-msvc.node only for Windows; darwin-arm64 and linux-arm64 are already covered.

Impact

Cherry Studio 2.1.7 ships anydoc in its native win32-arm64 Electron build and uses it for its document_to_markdown tool. On these machines every to_markdown call fails for .docx, .pdf, .xlsx, etc. Downstream issue: CherryHQ/cherry-studio#22566

Request

Please add aarch64-pc-windows-msvc to the napi target matrix/CI and publish @firecrawl/anydoc-win32-arm64-msvc (npm + GitHub release asset), matching the existing arm64 coverage on macOS and Linux. The only current workaround is running an x64 Node process under Windows emulation, which is slow and requires downstream apps to patch their integration.

If a native Windows ARM64 build is not planned, it would help to document that and/or expose a WASM fallback so consumers can degrade gracefully instead of failing at require() time.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions