-
-
Notifications
You must be signed in to change notification settings - Fork 59
Description
Summary
Request for information about Node.js 20+ support roadmap, or guidance on alternative approaches for packages requiring native Web Crypto API.
Context
I understand this project may be in maintenance mode, and I appreciate all the work that's gone into it! I'm hoping to either:
- Learn if Node 20+ support is planned, or
- Get guidance on recommended architectural patterns for this limitation
Real-World Use Case
Building a React Native app with WhatsApp integration (Baileys library). After consulting with Baileys maintainers, their bot confirmed:
"Node.js v22.21.1 or higher is strongly recommended... If nodejs-mobile is strictly capped at Node 18, you may continue to face significant hurdles with the Noise protocol handshake as it relies heavily on native node:crypto behaviors that polyfills struggle to replicate perfectly."
Tested polyfills:
- ❌ crypto-browserify - missing crypto.subtle
- ❌ webcrypto-shim - incomplete
⚠️ @peculiar/webcrypto - loads but fails during GCM operations
Question
Is there a plan to support Node 20+, or should developers architect around this limitation?
If there's no roadmap for Node 20+, that's totally understandable! Knowing this helps developers make informed decisions:
- Option A: Run modern packages on separate servers
- Option B: Wait for community updates
- Option C: Contribute to adding Node 20 support
Impact
This affects any package requiring:
- Native Web Crypto API (crypto.subtle)
- Modern crypto.Decipheriv behaviors
- Node 20+ specific features
"engines": { "node": ">=20" }in package.json
Examples: Baileys (WhatsApp), modern encryption libraries, blockchain packages
Environment
- React Native: 0.76.5
- nodejs-mobile-react-native: 18.20.4
- Android ARM64
Current workaround: Planning to run Baileys on separate Node 22+ server with WebSocket communication.
Thank you for maintaining this project! Any guidance on the path forward would be greatly appreciated. 🙏
Note: If there's interest but lack of time/resources, I'm open to exploring contribution options.