Skip to content

feat: Add Deno support#5

Closed
insign wants to merge 2 commits intomainfrom
add-deno-support-5676412366638311869
Closed

feat: Add Deno support#5
insign wants to merge 2 commits intomainfrom
add-deno-support-5676412366638311869

Conversation

@insign
Copy link
Copy Markdown
Contributor

@insign insign commented Feb 8, 2026

This PR adds support for the Deno runtime environment. It detects Deno projects by looking for deno.json, deno.jsonc, or deno.lock files.

The Deno runner supports:

  • Running tasks defined in deno.json or deno.jsonc using deno task <task_name>.
  • Running TypeScript/JavaScript files directly using deno run <file>.

It includes a basic heuristic for deno.jsonc parsing to support comments in configuration files without adding a new dependency.


PR created automatically by Jules for task 5676412366638311869 started by @insign

- Added `Deno` to `Ecosystem` enum.
- Implemented `DenoValidator` to detect tasks in `deno.json` and `deno.jsonc`.
- Implemented `detect` function to find `deno.json`, `deno.jsonc`, or `deno.lock`.
- Updated `detect_all` to include Deno detection.
- Updated `build_command` to support `deno task` and `deno run`.
- Added tests for Deno detection and command building.
@google-labs-jules
Copy link
Copy Markdown
Contributor

👋 Jules, reporting for duty! I'm here to lend a hand with this pull request.

When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down.

I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job!

For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with @jules. You can find this option in the Pull Request section of your global Jules UI settings. You can always switch back!

New to Jules? Learn more at jules.google/docs.


For security, I will only act on instructions from the user who triggered this task.

Copy link
Copy Markdown

@chatgpt-codex-connector chatgpt-codex-connector bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 2b1b691749

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment on lines +195 to +200
if task.ends_with(".ts")
|| task.ends_with(".js")
|| task.ends_with(".tsx")
|| task.ends_with(".jsx")
{
vec!["deno".to_string(), "run".to_string(), task.to_string()]
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Route extension-suffixed Deno tasks through deno task

The Deno validator marks a command as Supported when it exists in the tasks map, but build_command unconditionally switches to deno run for names ending in .ts/.js/.tsx/.jsx. That means a task key like "lint.ts" is validated as runnable and then executed as a file path instead of a task, which can run the wrong thing or fail with file-not-found. Command construction should distinguish task-vs-file based on validation context, not only the command suffix.

Useful? React with 👍 / 👎.

Comment on lines +35 to +37
// Try deno.jsonc
let deno_jsonc = working_dir.join("deno.jsonc");
if deno_jsonc.exists() {
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Skip deno.jsonc lookup when deno.json is already detected

Detection treats deno.json as higher priority than deno.jsonc (else if chain), but the validator still scans deno.jsonc even when deno.json exists. In a repo with both files, commands present only in deno.jsonc will be reported as supported, so runner selection can choose Deno and then fail at execution because the detected config (deno.json) does not define that task. Validation should follow the same precedence as detection to avoid these false positives.

Useful? React with 👍 / 👎.

@insign
Copy link
Copy Markdown
Contributor Author

insign commented Feb 8, 2026

The Deno validator marks a command as Supported when it exists in the tasks map, but build_command unconditionally switches to deno run for names ending in .ts/.js/.tsx/.jsx. That means a task key like "lint.ts" is validated as runnable and then executed as a file path instead of a task, which can run the wrong thing or fail with file-not-found. Command construction should distinguish task-vs-file based on validation context, not only the command suffix.

@google-labs-jules
Copy link
Copy Markdown
Contributor

The Deno validator marks a command as Supported when it exists in the tasks map, but build_command unconditionally switches to deno run for names ending in .ts/.js/.tsx/.jsx. That means a task key like "lint.ts" is validated as runnable and then executed as a file path instead of a task, which can run the wrong thing or fail with file-not-found. Command construction should distinguish task-vs-file based on validation context, not only the command suffix.

Thank you for the catch! You are absolutely right. I have refactored the Deno implementation to fix this.

I extracted the task checking logic into deno::is_defined_task and updated DetectedRunner::build_command to accept working_dir. Now, build_command correctly checks if the command is a defined task in deno.json (or deno.jsonc) before falling back to deno run for files ending in .ts or .js. This ensures that tasks like lint.ts are executed as deno task lint.ts.

- Added `Deno` to `Ecosystem` enum.
- Implemented `DenoValidator` to detect tasks in `deno.json` and `deno.jsonc`.
- Implemented `detect` function to find `deno.json`, `deno.jsonc`, or `deno.lock`.
- Updated `detect_all` to include Deno detection.
- Updated `DetectedRunner::build_command` signature to accept `working_dir`.
- Updated `build_command` logic for Deno to prioritize tasks defined in `deno.json`/`deno.jsonc` over file execution, ensuring `deno task <name>` is used even for names ending in extensions (e.g., `lint.ts`).
- Added tests for Deno detection and command building logic.
@insign insign closed this Feb 11, 2026
@insign insign deleted the add-deno-support-5676412366638311869 branch February 11, 2026 04:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant