Struct DenoFormatter 

pub struct DenoFormatter;

EcosystemFormatter for Deno manifests (D4).

Trait Implementations

impl DiagnosticMessages for DenoFormatter

fn yanked_message(&self) -> &'static str

S2: adopts deps-npm’s wording for the whole formatter (both jsr: and npm: specifiers), rather than the deps-core defaults (“yanked”). Spec.md US-002/ FR-013 treat cross-ecosystem wording divergence for the same npm package as a first-class bug, and EcosystemFormatter::yanked_message/yanked_label take only &self (no &dyn Dependency), so a per-scheme override is not possible without a deps-core trait change — this is the zero-cost fix available today.

fn yanked_label(&self) -> &'static str

Label for yanked versions in hover.

fn deprecated_message(&self) -> &'static str

Message for a package-level deprecation/abandonment diagnostic (issue #205).

fn deprecated_label(&self) -> &'static str

Label for a deprecated package in hover.

impl DiagnosticPolicy for DenoFormatter

fn yanked_diagnostic_applies_to( &self, dep: &dyn Dependency, _requirement: &VersionReq, ) -> bool

Scheme-aware (#448, fixing the #436 M1 divergence): for npm: specifiers, returns false unconditionally, mirroring NpmFormatter::yanked_diagnostic_applies_to’s post-#436 behavior — an exact-pin npm: dependency in deno.json (e.g. npm:lodash@4.17.20) no longer surfaces this diagnostic, consistent with the equivalent exact-pin package.json dependency.

For jsr: specifiers, applies unconditionally (true), matching the trait default that Cargo/PyPI/Dart already rely on (#454, dropping the exact-pin-only restriction this hook carried before #448 made it scheme-aware). Unlike npm’s deprecated — which #436 found routinely applied to every published version at once, making this diagnostic redundant with the package-level deprecation diagnostic (#205) — JSR’s yanked flag has no package-level counterpart to conflate with: JsrVersion’s impl_version! invocation leaves deprecation unset, so Version::deprecation() is structurally None for every JSR version and #205 never fires for jsr: dependencies. There is also no data gap: JSR’s meta.json (JsrRegistry::get_versions) returns every version’s yanked flag in one fetch, identical whether the manifest requirement is a range or an exact pin.

fn strict_semver_prerelease_exclusion(&self) -> bool

Whether this ecosystem’s requirement/version syntax follows strict SemVer 2.0.0 pre-release semantics: a pre-release version (X.Y.Z-pre) is excluded from matching requirement unless requirement itself pins to the same X.Y.Z tuple with a pre-release tag — the rule Cargo’s semver crate and npm’s node-semver both implement, and that compile_requirement’s matcher inherits from its underlying comparator.

fn supports_package_rename(&self) -> bool

Whether this ecosystem’s deprecation payload (crate::Deprecation::replacement) is safe to offer as a “Replace with X” rename quickfix.

impl OsvNaming for DenoFormatter

fn osv_package_name(&self, dep: &dyn Dependency) -> Option<String>

npm: dependencies map to OSV’s npm ecosystem via their bare name (D5); jsr: dependencies return None — OSV has no JSR ecosystem (live-verified: POST api.osv.dev/v1/query with {"ecosystem":"JSR"} returns code 3, invalid ecosystem) — which cleanly skips them from the scan rather than risking a cross-registry name collision.

fn osv_version_to_native(&self, version: &str) -> String

Converts a version string as it appears in an OSV advisory record (e.g. crate::osv::Advisory::fixed_versions) into this ecosystem’s own version namespace, as used in manifests and by the registry.

fn osv_version(&self, version: &str) -> String

Rewrites a native-ecosystem version string into the spelling OSV.dev’s SEMVER range matching expects.

impl PackageNaming for DenoFormatter

fn validate_package_name(&self, name: &str) -> Result<(), InvalidPackageName>

Validates the scheme-qualified name: jsr: requires the scoped @scope/name form (mirroring JSR’s own registration rules); npm: delegates to npm’s own validator on the bare name (ECOSYSTEM_GUIDE.md “npm Package Name Validation”); any other/missing scheme is rejected outright.

fn normalize_package_name(&self, name: &PackageName) -> String

Normalize package name for lookup (default: identity).

impl PackageRendering for DenoFormatter

fn format_version_for_text_edit(&self, version: &ConcreteVersion) -> String

Format version string for code action text edit.

fn package_url(&self, name: &PackageName) -> String

Get package URL for hover markdown.

fn format_version_replacing( &self, version: &ConcreteVersion, _current: &str, ) -> String

Format version as a replacement for the existing requirement text current, preserving current’s operator/pin style where the ecosystem supports more than one.

fn format_version_replacing_for( &self, _dep: &dyn Dependency, version: &ConcreteVersion, current: &str, ) -> String

Like format_version_replacing, but also carries the dependency identity version/current apply to.

fn suppress_package_url(&self, source: &DependencySource) -> bool

Whether hover should omit Self::package_url’s heading link for a dependency resolved against source.

fn is_position_on_dependency( &self, dep: &dyn Dependency, position: Position, ) -> bool

Detect if cursor position is on a dependency for code actions.

impl RequirementResolution for DenoFormatter

fn compile_requirement( &self, requirement: &VersionReq, ) -> Option<Box<dyn RequirementMatcher>>

Compiles requirement via node_semver::Range, the same crate deps-npm uses — correct for JSR too, since JSR mandates semver.

fn version_satisfies_requirement( &self, version: &ConcreteVersion, requirement: &str, ) -> bool

Check if a version satisfies a requirement string.

fn is_requirement_up_to_date( &self, requirement: &VersionReq, latest: &ConcreteVersion, ) -> bool

Whether an unresolved dependency (no lock-file version) should be reported as up to date against latest, given its declared requirement.

fn requirement_is_unresolved(&self, _requirement: &VersionReq) -> bool

Whether requirement could not be resolved to a concrete version constraint (e.g. an unexpanded property/variable placeholder rather than a real version or range).

fn requirement_status( &self, requirement: &VersionReq, latest: &ConcreteVersion, ) -> RequirementStatus

Tri-state variant of is_requirement_up_to_date that distinguishes “confirmed up to date” from “could not be resolved, so we don’t know.”

fn requirement_status_for( &self, dep: &dyn Dependency, requirement: &VersionReq, latest: &ConcreteVersion, ) -> RequirementStatus

Like requirement_status, but also hands the ecosystem the dependency itself — for an ecosystem whose requirement text alone is ambiguous between two shapes with different resolution rules, and which already computed the disambiguating classification once, at parse time, onto the dependency (deps-gitlab-ci’s PinStyle, #466 review M-c: a bare "1.2" is Partial under its component: pin grammar but Branch under its simpler project: ref grammar — indistinguishable from the text alone).

fn requirement_is_undecidable_given_available( &self, _requirement: &VersionReq, _available: &[ConcreteVersion], ) -> bool

Whether this ecosystem’s registry can silently omit a published version from available in a way indistinguishable from “never published” — and, if so, whether requirement names a version-space region that specific omission could explain, given the versions actually observed in available.

fn manifest_requirement_is_resolved_version(&self, dep: &dyn Dependency) -> bool

Whether dep’s manifest version-requirement line is itself the exact version already selected — never a range.

impl SourcePolicy for DenoFormatter

fn can_resolve_source(&self, source: &DependencySource) -> bool

Whether this ecosystem’s registry can resolve version data for source.

fn source_is_public_registry_content(&self, source: &DependencySource) -> bool

Whether source’s content is exactly the default public registry’s — safe to treat as such for OSV vulnerability scanning, cache-key signature construction, and hover heading links.