Conversation
- 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.
|
👋 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 New to Jules? Learn more at jules.google/docs. For security, I will only act on instructions from the user who triggered this task. |
There was a problem hiding this comment.
💡 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".
src/detectors/mod.rs
Outdated
| 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()] |
There was a problem hiding this comment.
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 👍 / 👎.
src/detectors/deno.rs
Outdated
| // Try deno.jsonc | ||
| let deno_jsonc = working_dir.join("deno.jsonc"); | ||
| if deno_jsonc.exists() { |
There was a problem hiding this comment.
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 👍 / 👎.
|
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 |
- 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.
This PR adds support for the Deno runtime environment. It detects Deno projects by looking for
deno.json,deno.jsonc, ordeno.lockfiles.The Deno runner supports:
deno.jsonordeno.jsoncusingdeno task <task_name>.deno run <file>.It includes a basic heuristic for
deno.jsoncparsing to support comments in configuration files without adding a new dependency.PR created automatically by Jules for task 5676412366638311869 started by @insign