ci: build and test the extension on push

[Ryanmello07]

First CI for this repo: build and test on every push and PR to main, plus manual dispatch. One file, .github/workflows/build-and-test.yml, nothing else changes.

It is green, and it is fast: the whole job takes about a minute.

What it runs

One ubuntu-latest job, using the repo's own entry points:

Step	Command	Result
Install	npm ci --no-audit --no-fund	clean
Lint	npm run lint	12 pre-existing errors — reported, non-blocking (see below)
Type-check tests	npm run test:types	clean
Test	npm test	28 tests / 3 files passed in 0.4s
Build (chrome)	npm run build	built in ~2s
Build (firefox)	npm run build:firefox	built in ~2s
Verify	—	both zips present at ~9.9 MB, firefox manifest confirmed patched
Upload	actions/upload-artifact@v4	both zips, for inspection only

test:types is checked separately because tsconfig.test.json is not referenced from tsconfig.json — the tsc -b inside npm run build never sees tests/. test.sh checks it separately for the same reason. The two build commands are exactly what the Makefile runs.

The job carries timeout-minutes: 15 (a hang guard, not a budget — it finishes in ~1 min) and a concurrency group keyed on workflow + ref with cancel-in-progress, so pushing twice to a branch does not leave two runs racing.

The one judgement call: lint does not gate

eslint . fails on a fresh checkout of main with 12 errors that predate this PR:

• 9 × @typescript-eslint/no-explicit-any — src/background/index.ts:17,21,110, src/utils/connection-manager.ts:61, src/utils/kill-switch-apply.ts:9, src/utils/proxy-manager.ts:39,40, src/utils/sso.ts:51, src/utils/use-provider-list-enhanced.ts:193
• 1 × unused _tab — src/background/index.ts:126
• 2 × react-hooks "Cannot access refs during render" — src/utils/use-connection-manager.ts:27-28, where authFnRef.current and removeFnRef.current are assigned during render

None are auto-fixable, so gating lint means real code changes. The first push of this workflow proved the cost of gating: lint failed and the tests and both builds never ran at all.

So lint gets the same mechanism connect/test.yml gives its non-blocking extender step — it still runs, still reports in the log, but a pre-existing failure is not allowed to gate the build-and-test this workflow exists for. One honest difference from that precedent, called out in the file too: connect's step covers a genuinely flaky test, this one covers deterministic debt, so it will be red on every single run until someone fixes it, and a permanently red step is easier to stop noticing than a sometimes-red one.

Maintainer decision: leave it reported-but-non-blocking as shipped, or fix the 12 on main first and drop continue-on-error. The comment in the file says to drop it once main lints clean. Happy to flip it.

No secrets

Nothing here needs a credential, and nothing is skipped to avoid one:

• @urnetwork/sdk-js (0.0.1-beta.5) and @urnetwork/localizations (0.0.6) are public on registry.npmjs.org — every entry in package-lock.json resolves from that one registry, and npm ci ran clean with no token.
• The tests are offline by construction: tests/setup.ts stubs fetch to reject, so a leaked network call fails loudly rather than reaching api.bringyour.com.
• No signing, no store upload, no npm publish, no release. The two zips are a CI artifact only.

Node version

package.json declares no engines and no packageManager, so the repo pins nothing itself. The release pipeline (build/all/run.sh) gates on node 24.14.1 / npm 11.11.0, but that is a whole-pipeline reproducibility gate that fires once before any repo is pulled. For this repo alone the binding floors are vite 7's ^20.19.0 || >=22.12.0 and vitest 4's ^20 || ^22 || >=24 — together, node ^20.19 || ^22.12 || >=24. The workflow pins the node 24 major to stay on the line the pipeline ships from, without pretending the patch matters.

Note this differs from web/build.yml's node-version: latest, which is unpinned and drifts onto whatever shipped that week, including non-LTS odd majors. lts/* would also satisfy the floors if you prefer that.

One known divergence from the release build

build.sh rsyncs the sibling localizations checkout over the installed package before building, because for a 0.0.x dependency npm treats ^ as exact — a key added to the store is invisible until the package is republished and the dependency bumped. CI has no sibling checkout, so scripts/build-locales.js takes its own documented fallback and uses published @urnetwork/localizations@0.0.6. The build is complete and real; it just validates against the published key set, so CI will not catch localization key drift (registry latest is already 0.0.7 against the locked 0.0.6).

Closing that gap is possible but is not a one-liner: localizations/index.js imports js-yaml as a bare specifier, and Node resolves those only up ancestor directories, so a bare sibling clone cannot see this repo's node_modules — and resolveLoadAllKeys does its await import(siblingIndex) with no try/catch, so it would fail the prebuild rather than fall back. It needs the clone and npm ci inside it. Deliberately left out of a first CI to keep the workflow small; say the word and I will add it.

What this deliberately does not do

No release, no signing, no store/AMO upload, no publish, no secrets, and no browser-driven end-to-end tests. Purely: does it install, type-check, test, and build for both targets.

Draft: opened for review, not to merge as-is.