Enable Deno runtime support for Wrangler CLI

[jimmont]

Describe the solution

Feature Request: Native Deno Support for Wrangler

User Stories

Developer Experience

As a Deno developer, I want to use Wrangler without Node.js dependencies so that I can:

• Maintain a consistent, secure development environment across all my projects
• Leverage Deno's built-in TypeScript support and modern ESM imports
• Avoid the complexity and security concerns of npm/node_modules
• Use Deno's permission system for better security when running CLI tools

Platform Engineering

As a platform engineer, I want our deployment tools to support multiple runtimes so that I can:

• Reduce developer onboarding friction by supporting their preferred tools
• Standardize on modern, secure development practices across teams
• Minimize the number of runtime dependencies in our development pipeline
• Choose tools based on technical merit rather than ecosystem lock-in

Business Strategy

As a platform provider, I want to support widely-adopted runtimes so that I can:

• Attract developers from growing market segments to my platform
• Differentiate my platform with superior developer experience
• Reduce barriers to adoption for new users
• Stay competitive as the edge computing market evolves

Technical Leadership

As a technical lead, I want deployment tooling that works with modern runtimes so that I can:

• Make technology choices based on security and performance rather than tooling limitations
• Adopt new technologies without requiring complete toolchain rewrites
• Reduce cognitive overhead for developers switching between projects
• Future-proof our development stack against ecosystem changes

Context: What's Changed

This request builds on previous discussion #6049 with significant new context:

Deno 2.0 (October 2024) resolved previous technical barriers:

• Full npm package compatibility via npm: specifiers
• Production-ready Node.js API compatibility
• Mature ecosystem suitable for enterprise development

Validated Market Demand:

• Denoflare (2K+ GitHub stars): Community-built alternative specifically for Cloudflare
• Brawler: Wrapper tool exists because developers want this workflow
• 3+ years of requests: Sustained community interest across multiple issues

Competitive Landscape:

• Edge computing adoption accelerating across industry
• Other platforms exploring alternative runtime support
• Developer experience becoming key differentiator for platform adoption

Technical Implementation

Current Blocker:

$ deno run npm:wrangler
error: unexpected argument '--experimental-vm-modules' found
error: unexpected argument '--no-warnings' found

Minimal Solution (Runtime Detection):

const isDeno = typeof Deno !== 'undefined';
const nodeSpecificFlags = ['--experimental-vm-modules', '--no-warnings'];
const cleanArgs = isDeno 
  ? process.argv.filter(arg => !nodeSpecificFlags.includes(arg))
  : process.argv;

Implementation Approach:

1. Phase 1: Remove blocking CLI flags when running under Deno
2. Phase 2: Test deployment pipeline compatibility
3. Phase 3: Enhanced integration based on usage metrics

Risk Assessment:

• Low risk: Changes are conditional and don't affect existing Node.js workflows
• High impact: Enables entire new developer segment with minimal engineering investment

Acceptance Criteria

Minimum Viable:

• deno run npm:wrangler deploy works without errors
• deno run npm:wrangler dev provides local development server
• All existing Node.js functionality remains unchanged

Success Metrics:

• Deno developers can deploy to Cloudflare Workers without Node.js installation
• Community stops building workaround tools
• Increased developer adoption from Deno ecosystem

Quantified Business Case

Market Context:

• Deno ecosystem growth: Multiple major releases, enterprise adoption by Slack, GitHub
• Community validation: 3+ years of GitHub requests, multiple workaround tools built
• Developer preference trends: Modern runtime adoption accelerating in edge computing
• Cloudflare positioning: Workers well-suited for developers seeking modern deployment

Competitive Landscape:

• Alternative platforms exist (Deno Deploy, Vercel, Netlify)
• Community building workarounds rather than switching platforms (positive signal)
• Runtime flexibility increasingly important for developer platform choice
• Technical barriers preventing evaluation by Deno developers

Developer Experience Gap:

• Current barrier: Deno developers cannot evaluate Workers without Node.js installation
• Community response: Building tools like Denoflare rather than abandoning Cloudflare
• Opportunity: Remove artificial barrier to platform evaluation

Risk of Inaction:

• Community building competing solutions (Denoflare has 2K+ stars, growing)
• Developers choosing Vercel/Netlify specifically for runtime flexibility
• Edge computing developers = high-value segment (enterprise adoption, high usage)

Engineering Assessment:

• Primary blocker: Node.js-specific CLI flags preventing execution
• Initial investigation: Runtime detection and conditional flag handling
• Scope: Focused on enabling basic deno run npm:wrangler functionality
• Validation needed: Testing deployment pipeline compatibility with Deno runtime

Implementation Approach:

• Phase 1: Remove immediate CLI flag blockers
• Phase 2: Comprehensive testing of core workflows (dev, deploy, etc.)
• Phase 3: Address any discovered compatibility issues
• Monitoring: Track usage and identify enhancement opportunities

Alternative Implementation Strategies:

• Option A: Conditional logic in existing npm package (npm:wrangler with runtime detection)
• Option B: Separate JSR package (jsr:@cloudflare/wrangler) for Deno-specific implementation
• Option C: Dual entry points in single package (e.g., npm:wrangler/deno)

Each approach offers different trade-offs between implementation complexity and ecosystem integration.

Risk Assessment:

• Implementation risk: Low (conditional logic, no changes to Node.js path)
• Unknown factors: Potential edge cases in Deno's npm compatibility layer
• Mitigation: Incremental rollout, comprehensive testing before general availability

Risk Analysis

Risk of Implementation:

• Technical complexity: Initial scope limited to CLI compatibility
• Testing requirements: Need validation across core Wrangler workflows
• Support considerations: Potential for Deno-specific issues or questions

Risk of Inaction:

• Developer evaluation barrier: Deno developers cannot easily try Workers
• Community fragmentation: Workaround tools create inconsistent experience
• Platform positioning: Missing opportunity to support modern development preferences

Decision Criteria:

• Technical feasibility: Can basic compatibility be achieved reliably?
• Community value: Does this remove significant barriers for developer evaluation?
• Strategic fit: Does this align with Workers' position in modern development?

Success would be measured by: Deno developers able to deploy and develop Workers without requiring Node.js installation.

Addressing Common Concerns

"Limited demand signal"

• Evidence: Sustained community requests across multiple years
• Validation: Community building workaround tools (Denoflare, Brawler)
• Context: Developers choosing to build tools rather than abandon platform

"Engineering complexity unknown"

• Approach: Start with limited scope (basic CLI compatibility)
• Validation: Technical spike to assess real effort required
• Mitigation: Incremental implementation with testing at each phase

"Maintenance and support burden"

• Scope: Initial implementation focuses on existing npm compatibility
• Support: Leverage Deno 2.0's npm compatibility for most functionality
• Monitoring: Track issues and usage patterns before expanding scope

"Resource prioritization"

• Value: Removes artificial barrier to platform evaluation
• Effort: Focused on specific, well-defined compatibility issue
• Impact: Enables developer choice without affecting existing workflows

The core question: Should technical barriers prevent developers from evaluating Workers when workaround solutions exist?

Request

Given the changed technical landscape with Deno 2.0 and validated community demand, we request reconsideration of native Deno support in Wrangler.

Proposed next steps:

1. Brief technical spike to validate feasibility (estimated 1-2 days)
2. Community beta testing with interested developers
3. Gradual rollout based on usage metrics and feedback

The technical implementation is straightforward, and the strategic opportunity to be first in market may be time-sensitive.

[penalosa]

Thanks for raising this issue. However, nothing has fundamentally shifted since https://github.com/cloudflare/workers-sdk/issues/6049#issuecomment-2169770004—in particular, none of the benefits of Deno (e.g. native TS support) apply to using Wrangler as an orchestrator for the workerd runtime, which is it's primary purpose.

In particular, the maintenance and testing burden would be too high (this is also why we don't support Bun). While Deno has relatively good Node compat, Wrangler (and Miniflare) are fairly complex applications which exercise a lot of the Node.js API surface, and it's unclear that the additional testing overhead to make sure things work in Deno would be worthwile.