fix(publish): honor jsr.json fallback and flag config conflicts

[Pinta365]

Summary

• make deno publish fall back to jsr.json(c) when no publishable deno.json(c) exists, so packages that keep their metadata in jsr.json work as expected
• surface a conflicting-publish-config diagnostic (with a hint and docs link) when both config files define package metadata, so authors resolve the ambiguity before publishing

Fixes #22651.

Testing

• cargo test -p deno -- maybe_jsr_package_config
• ./tools/format.js
• ./tools/lint.js

[CLAassistant]

All committers have signed the CLA.

[coderabbitai[bot]]

Walkthrough

This change adds support for discovering and handling jsr.json configuration files throughout the codebase. The DenoOrPkgJson enum is replaced with a new ConfigFolder struct that aggregates deno.json, jsr.json, and package.json sources. A new ConflictingPublishConfig diagnostic is introduced to detect when both deno.json and jsr.json contain publish configurations. The WorkspaceFactoryOptions now uses a discover_jsr_config flag instead of additional_config_file_names. Workspace discovery logic is extended to load jsr.json when the discovery option is enabled, and the publish flow is updated to process JSR configs alongside Deno configs. An integration test validates publishing with jsr.json as a configuration source.

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 29.17% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly summarizes the main changes: enabling jsr.json fallback for publish and detecting conflicting publish configs.
Description check	✅ Passed	The description accurately covers the two main objectives: jsr.json fallback support and conflicting config detection, with testing details provided.
Linked Issues check	✅ Passed	The PR addresses issue #22651 by implementing jsr.json fallback when deno.json lacks publish metadata, and adds conflict detection when both files define package metadata.
Out of Scope Changes check	✅ Passed	All changes are scoped to publish configuration discovery and conflict detection. The workspace, factory, and config changes directly support the jsr.json fallback and conflict flagging objectives.

✨ Finishing touches

• [ ] 📝 Generate docstrings

🧪 Generate unit tests (beta)

• [ ] Create PR with unit tests
• [ ] Post copyable unit tests in a comment

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[Pinta365]

@coderabbitai help

[coderabbitai[bot]]

Chat

There are 3 ways to chat with CodeRabbit:

• Review comments: Directly reply to a review comment made by CodeRabbit. Example:
  • I pushed a fix in commit <commit_id>, please review it.
  • Open a follow-up GitHub issue for this discussion.
• Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query.
• PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
  • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
  • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.

CodeRabbit commands

These commands are invoked using PR/Issue comments.

• @coderabbitai pause to pause the reviews on a PR.
• @coderabbitai resume to resume the paused reviews.
• @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
• @coderabbitai full review to do a full review from scratch and review all the files again.
• @coderabbitai summary to regenerate the summary of the PR.
• @coderabbitai evaluate custom pre-merge check --instructions <custom-checks-instructions> --name <custom-checks-title> [--mode <error|warning>] to validate the custom pre-merge checks instructions. Defaults to error when --mode is omitted.
  • @coderabbitai ignore pre-merge checks to override pre-merge checks and get an approval on PR.
  • @coderabbitai run pre-merge checks to run pre-merge checks on the pull request.
• @coderabbitai generate docstrings to generate docstrings for this PR.
• @coderabbitai generate sequence diagram to generate a sequence diagram of the changes in this PR.
• @coderabbitai generate unit tests to generate unit tests for this PR.
• @coderabbitai resolve to resolve all the CodeRabbit review comments.
• @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
• @coderabbitai help to get help.

Other keywords and placeholders

• Add @coderabbitai ignore or @coderabbit ignore anywhere in the PR description to prevent this PR from being reviewed.
• Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
• Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit configuration file (.coderabbit.yaml)

• You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
• Please see the configuration documentation for more information.
• You can also validate your configuration using the online YAML validator.
• If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Status, support, documentation and community

• Visit our status page to check the current availability of CodeRabbit.
• Create a ticket on our support page for assistance with any issues or questions.
• Visit our documentation site for detailed information on how to use CodeRabbit.
• Join our Discord community to connect with other users and get help from the community.
• Follow us on X/Twitter for updates and announcements.

[Pinta365]

Actionable comments posted: 0

🧹 Nitpick comments (1)

cli/tools/publish/mod.rs (1)> 1573-1625: Tests cover core scenarios.

The tests verify:

1. Reading valid jsr.json successfully
2. Strict mode validation (missing name errors)

Consider adding a test for non-strict mode behavior: verify that maybe_jsr_package_config with strict=false returns None (rather than erroring) when jsr.json exists but lacks required fields.

📜 Review details

@coderabbitai I added a test as a reference to the nitpick comment, (8a3e817). Review it.

[coderabbitai[bot]]

[!TIP] For best results, initiate chat on the files or code changes.

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Get the diff for commit 8a3e817 to see what test was added
git show 8a3e817

Length of output: 1257

---

@Pinta365, the test looks good! It correctly addresses the nitpick by verifying that maybe_jsr_package_config with strict=false returns None when jsr.json exists but lacks the required name field. The test:

✅ Creates a jsr.json with only a version field (missing name)
✅ Calls the function with strict=false
✅ Asserts the result is None rather than an error

The implementation is clean and the test name clearly describes the expected behavior. This completes the test coverage for the non-strict mode fallback scenario.

[Pinta365]

Thanks for the review @dsherret, would you mind going through these changes?

• jsr.json fallback in WorkspaceDirectory::maybe_package_config() (single source of truth)
• Conflict detection in Workspace::diagnostics()
• CLI consumes workspace diagnostics, no duplication

Also noticed when I tried this out in a local workspace project that looked like this

workspace/
├── deno.json              # Root workspace configuration
├── LICENSE.md             # License file
├── main.ts                # Main entry point that imports both packages
├── package1/
│   ├── deno.json         # Package1 Deno configuration
│   ├── jsr.json          # Package1 JSR metadata (name, version, exports)
│   └── mod.ts            # Package1 module exports
└── package2/
    ├── deno.json         # Package2 Deno configuration (includes JSR metadata)
    └── mod.ts            # Package2 module exports

Deno run main.ts failed to resolve the "package1"-package with jsr.json packaging so I updated. resolver_jsr_pkgs() to use the same fallback logic (check deno.json first, then jsr.json). This ensures runtime resolution works correctly with jsr.json fallback, matching the behavior of maybe_package_config().

Might have to look into other sections also? Like the LSP for like ide extensions? but that's probably outside of this scope for sure.

[dsherret]

We don't want to support jsr.json outside of deno publish. It's too many config files to probe for (slow) and if someone wants to use deno with it then they should use a deno.json. Maybe one day we'll add the ability to extend a jsr.json from a deno.json

[Pinta365]

We don't want to support jsr.json outside of deno publish. It's too many config files to probe for (slow)

Right. Ok, I understand. I'll revert the deno run resolve then. Im going to have to get back to it tomorrow though sadly.

[Pinta365]

Alright. Please check this out when you get a chance @dsherret. I reverted the change to the runtime package resolution.