Commit activity
Last 12 weeks · 198 commits
Community health
2 of 6 standards met
37
✓README✓License○Contributing○Code of Conduct○Issue Template○PR Template
Recent PRs & issues
Active · Last activity 18h ago
See all on GitHub →
The skeletons of the frameworks at https://docs.deno.com/runtime/desktop/frameworks/ are generated with a (e.g. by ). The schema of that doesn't have the key that expects. It would help to have some guidance on the best practice for this situation: keep both and ? fold into ?
Adds documentation pages for the eleven oxlint "unicorn" correctness rules being ported to deno_lint as native rules. Each page follows the existing format — frontmatter tag, a short description, prose explaining the rationale, and Invalid/Valid code examples. The rule list is generated by walking , so no index changes are needed. Documented rules: , , , , , , , , , , and . These pair with the rule implementations in deno_lint (PRs #1520, #1522– #1531). All eleven rules are tagged , mirroring the tag on the rule implementations; that on-by-default choice is pending maintainer sign-off on the deno_lint PRs, so the frontmatter here should be confirmed alongside those.
Adds documentation pages for the oxc-correctness batch of oxlint rule ports. These accompany the rule work in — is implemented (denoland/deno_lint#1521) and the rest are documented ahead of their ports so the spec and the docs land together. Pages added: erasing-op const-comparisons double-comparisons bad-char-at-comparison bad-comparison-sequence bad-min-max-func bad-object-literal-comparison bad-replace-all-arg bad-array-method-on-arguments missing-throw number-arg-out-of-range only-used-in-recursion uninvoked-array-callback Each follows the existing rule-page format (front-matter tags, a description, and Invalid/Valid examples) and the sidebar picks them up automatically via . Content is grounded in the upstream oxc rule definitions, with one correction: documents that a non-global regex passed to throws a (per the spec), rather than oxc's description that only the first match is replaced. The pages are tagged , matching oxc's classification. If the rules ship opt-in instead, the front-matter tag should be dropped to match — this tracks the same on-by-default decision as the rules themselves. Note: a few of these pages describe rules that are not yet implemented in , so the corresponding entries will appear in the sidebar before the rules are released.
Recent fixes
The example at https://docs.deno.com/runtime/desktop/configuration/#full-example, when used with the Hello desktop sample in , produces a repeated warning:
The publishing guide mentioned only in passing, with no coverage of how it drives a multi-package release. This adds an "Automating workspace releases" subsection under Workspaces that explains running it at the workspace root with no increment: it derives each member's bump from Conventional Commits since the last release, rewrites the constraints in the root import map, and prepends a changelog entry. It also points readers at a working reference. The Deno Standard Library's workflow runs , formats the generated notes, and opens a release PR; merging it and publishing a GitHub release triggers a second workflow that runs for every member. The new copy links directly to that workflow and to the std so readers can adapt a hands-off, Conventional-Commits-driven release for their own workspace. This is informed by setting that workflow up in denoland/std, where the step in particular turned out to be necessary because the generated notes need wrapping before they pass the lint check.
Feature CSS module imports landed in Deno via denoland/deno#35093 (behind the flag, towards denoland/deno#11961). Importing a stylesheet with an import attribute now evaluates to a , matching what Chrome and Firefox ship: Dynamic imports work too: The primary use case is running unmodified browser module graphs in Deno (SSR and testing of web components), where a CSS import currently kills module loading before any code runs. What needs documenting How to enable the feature: flag (and the field in ). Static and dynamic import syntax. The minimal surface that Deno implements: — returns a frozen array of (not a live ); each access creates a fresh array. / — top-level rules are dropped (matching the CSSOM constructed-stylesheet behavior). — verbatim text of one top-level rule. constructor (constructor like // are not supported). Important limitations to call out: Deno has no DOM, so a sheet can't be adopted anywhere; the implementation is backed by the raw CSS text. uses a naive top-level rule split, not a real CSS parser/object model — methods like / are not implemented. Reading a CSS file requires read permission (). Note the unstable status (API yet to be vetted; subject to change). References Implementation PR: denoland/deno#35093 Tracking issue: denoland/deno#11961 Spec: https://html.spec.whatwg.org/multipage/webappapis.html#css-module-script
Structured data for AI agents
Repository: denoland/docs. Description: Deno documentation, examples and API Reference. Powered by Lume. Stars: 198, Forks: 369. Primary language: TypeScript. Languages: TypeScript (79.1%), CSS (14.4%), JavaScript (5.1%), MDX (1.4%), Dockerfile (0%). License: MIT. Homepage: https://docs.deno.com Topics: deno, hacktoberfest. Open PRs: 24, open issues: 50. Last activity: 18h ago. Community health: 37%. Top contributors: thisisjofrank, bartlomieju, kwhinnery, denobot, dsherret, lucacasonato, crowlKats, marvinhagemeister, philhawksworth, josh-collinsworth and others.