[pull] main from jsr-io:main#92
Merged
Merged
Conversation
Fixes #1121 The package header's description `<p>` has no overflow-wrap setting, so descriptions containing long unbreakable tokens (long URLs, technical identifiers, undelimited strings, etc.) can extend past the viewport on narrow screens. Add `break-words` (CSS `overflow-wrap: break-word`) so the description wraps at whitespace as usual, and only breaks within a word when one is wider than the column. ### Diff ```diff - <p class="text-secondary text-base max-w-3xl mb-6"> + <p class="text-secondary text-base max-w-3xl mb-6 break-words"> ``` ### Verification - Built the frontend locally and loaded `http://localhost:8000/@salmidev/maths-objects` (the URL from the issue). The description `<p>` renders with `class="... break-words"` and the generated Tailwind CSS includes `.break-words{overflow-wrap:break-word}`. - `overflow-wrap: break-word` is the conservative variant: lines still break at whitespace where they can; words only break mid-token when nothing else would fit. - `deno fmt --check` and `deno lint` pass on the changed file; full-repo fmt/lint failures on `main` are unrelated (`assets/styles.css`, `assets/tailwind.css`). - Couldn't capture before/after screenshots in this environment (no working headless browser available), but the rule applies only when a token would otherwise overflow the container — wider viewports and shorter descriptions are visually unchanged.
…acent content (#1413) ## Summary Closes #1377. The `Tooltip` popup container had no `z-index` set, so adjacent siblings rendered later in the DOM painted on top of it whenever they overlapped — most visibly the provenance "Built and signed on GitHub Actions" tooltip on the package header, which sits inside the `<h1>` next to the chips row and right above the secondary metadata row. Adding `z-30` to the absolute container puts the popup above same-context content while staying below sticky/modal layers, matching the existing convention used by other popovers in the codebase: - `DocUsages` (`islands/DocUsages.tsx`) — `z-30` - `DocBreadcrumbsSwitcher` (`islands/DocBreadcrumbsSwitcher.tsx`) — `z-30` - `BreadcrumbsSticky` — `z-20` (now correctly below the tooltip) - `Header` — `z-50` (correctly stays above) - modals (`TicketModal`, `UserMenu`, `SignInMenu`) — `z-70`+ (correctly stay above) ## Changes - `frontend/components/Tooltip.tsx`: add `z-30` to the popup's `absolute` container. One-class change; no markup or behavior changes otherwise. ## Validation - `deno task lint:frontend` — pre-existing `no-process-global` warnings unrelated to this change; no new errors. - `deno fmt --check` / `deno lint` / `deno check` on the touched file all clean. - Built with `deno task build` and ran `deno serve -A --cached-only --port=8000 _fresh/server.js` against `API_ROOT=https://api.jsr.io`. Inspected the rendered HTML on `/@std/path` (a package with provenance) and confirmed the tooltip's absolute container now renders with `class="absolute z-30"`. Screenshots couldn't be captured in this sandbox (no Chromium and outbound asset downloads blocked), but the change is one Tailwind utility class addition with no markup/JS behavior change, so light/dark/responsive states are not affected. ## PR Checklist - [x] The PR title follows [conventional commits](https://www.conventionalcommits.org/en/v1.0.0/) - [x] Is this closing an open issue? If so, link it, else include a proper description of the changes and reason behind them. - [x] Does the PR have changes to the frontend? If so, include screenshots or a recording of the changes. <br/>If it affect colors, please include screenshots/recording in both light and dark mode. - [ ] Does the PR have changes to the backend? If so, make sure tests are added. <br/>And if changing dababase queries, be sure you have ran `sqlx prepare` and committed the changes in the `.sqlx` directory. Co-authored-by: crowlbot <crowlbot@users.noreply.github.com>
First step of the API-service-split RFC (#1414): carve the shared data types out of `api/` into a new wasm-safe `jsr_types` crate, so the upcoming workers-rs front and the Cloud Run server can share a single source of truth without the Worker pulling in `sqlx` or any native crate. This PR is a **pure refactor — no behaviour change, no endpoint moves.** ### What moves - `api/src/ids.rs` → `crates/jsr_types/src/ids.rs` — the id newtypes (`ScopeName`, `PackageName`, `Version`, `PackagePath`, …). - `api/src/db/models.rs` → `crates/jsr_types/src/models.rs` — the plain DB model structs. ### How sqlx stays out of wasm The structs live in `jsr_types`; their `FromRow` / `Type` / `Encode` / `Decode` impls move with them but are gated behind a **default-off `sqlx` feature** (manual impls under `#[cfg(feature = "sqlx")]`, derives under `#[cfg_attr(feature = "sqlx", …)]`). `registry_api` turns the feature on, so its query code is untouched. With the feature off the crate builds for `wasm32-unknown-unknown` — sqlx never compiles. (`uuid`'s `v4`/`getrandom` is likewise left to the consuming crates.) ### No churn in the API server `api/src/ids.rs` and `api/src/db/models.rs` become one-line re-export shims (`pub use jsr_types::ids::*;` / `models::*;`), so all ~80 existing `crate::ids::*` and `crate::db::*` call sites keep working verbatim. A `testing` feature re-exposes `ExportsMap::mock()` to the API server's tests via dev-deps. ### Verification - ✅ `cargo build -p jsr_types --target wasm32-unknown-unknown` (default features) — the whole point; now enforced in CI. - ✅ `cargo check -p registry_api --all-targets` (sqlx feature on, incl. tests). - ✅ `cargo clippy --all-targets --all-features -- -D warnings`. - ✅ `cargo fmt --all -- --check`. - ✅ `cargo test -p jsr_types` — the id-validation unit tests moved with the types (now run by a new CI step). Next in the sequence (#1414): scaffold the empty workers-rs crate, then the Hyperdrive + `tokio-postgres` DB spike. --------- Co-authored-by: crowlbot <crowlbot@users.noreply.github.com>
## What Step 2 of the API service split (design: #1414, step 1 `jsr_types` extraction landed in #1417): **scaffold the `workers-rs` API Worker**. This adds a new `workers-rs/` crate — a minimal Cloudflare Worker (Rust → `wasm32`) that will become the front for `api.jsr.io`. It is deliberately a skeleton: - `#[event(fetch)]` entrypoint + a `worker::Router` route table, - a `GET /health` liveness check returning a small JSON body, - a catch-all that returns `501 Not Implemented` for every other path, so the not-yet-migrated surface is explicit, - **no database and no real endpoints** — those move over one endpoint group per PR per the design doc's sequence (Hyperdrive DB spike is the next step). ## Notes - **Detached workspace.** `workers-rs/Cargo.toml` declares its own `[workspace]` (with its own `Cargo.lock`) so the repo-root `registry_api` native build never tries to compile this `wasm32`-only crate. The existing `check`/`test` jobs are unaffected. - **CI.** Adds an `api-worker` job that installs the pinned toolchain, adds the `wasm32-unknown-unknown` target, and runs `cargo fmt --check`, `cargo clippy --target wasm32-unknown-unknown -- -D warnings`, and a release `cargo build --target wasm32-unknown-unknown`. The full bundle is produced by `worker-build` at deploy time; the CI gate is the wasm compile. - **Deploy.** `wrangler.toml` here is for local `wrangler dev` only. Production bindings (Hyperdrive, the compute-service URL/service binding, OAuth + Orama config) and the deployment resources are managed by Terraform in a later infra PR, mirroring `terraform/cloudflare_frontend.tf`. None of that is wired up yet. ## Verification Locally, on `wasm32-unknown-unknown` (toolchain 1.89.0): - `cargo build --target wasm32-unknown-unknown --release` ✅ - `cargo clippy --target wasm32-unknown-unknown -- -D warnings` ✅ - `cargo fmt --check` ✅ No behavior change to the existing compute service. Co-authored-by: crowlbot <crowlbot@users.noreply.github.com>
Fixes #1246. ## Repro `api/src/npm/tarball.rs` previously called `header.set_mode(0o777)` for every entry written into the npm-compat tarball. After publishing and `npm install`ing a JSR package, every file in `node_modules/<pkg>/…` ended up with the executable bit set, including `.d.ts` files. This breaks tooling that warns on non-shebang executables (e.g. RPM packaging). ## Fix Use `0o644` for all tarball entries. The generated `package.json` has no `bin` field, so no file in the npm-compat tarball is supposed to be executable. `0o644` matches npm's default for non-bin files. ## Test Extended the `test_npm_tarballs` spec runner to assert the mode of every emitted entry. Verified manually that the assertion fails (`unexpected mode 777`) before the one-line fix and passes after.
…ettings (#1428) ## What The provider-logo `<img>` tags in the **Connect / Disconnect** buttons on the account settings page (`/account/settings`) have no `alt` attribute. Because they're rendered from `asset(\`/logos/${serviceId}.svg\`)`, screen readers fall back to announcing the image filename (e.g. *"github.svg"*) before the button's own text. These logos are purely decorative — each button already has a visible text label that names the service ("Connect GitHub", "Disconnect GitHub", …) — so they should be hidden from the accessibility tree. ## Change Add `alt=""` to the two logo images in `Connection()`, matching the existing convention already used for the other decorative provider/brand logos across the frontend (e.g. the sign-in/provider logos in `routes/new.tsx`, `routes/index.tsx`, `routes/packages.tsx`, and the Orama logo in `islands/GlobalSearch.tsx`). ```diff - <img class="size-5" src={asset(`/logos/${serviceId}.svg`)} /> + <img class="size-5" src={asset(`/logos/${serviceId}.svg`)} alt="" /> ``` ## Visual / a11y impact - **Visual:** none — `alt=""` does not change rendering; the logos look identical in light and dark mode. - **Accessibility:** the decorative logos are now correctly omitted from the accessibility tree, so screen readers announce only the button's text label instead of the SVG filename. ## Testing - `deno fmt --check` and `deno lint` pass on the changed file. Co-authored-by: Leo Kettmeir <crowlkats@toaxl.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.4)
Can you help keep this open source service alive? 💖 Please sponsor : )