Claude
f9111c06a7
CI / lint (push) Successful in 3s
CI / extension-version (push) Successful in 4s
CI / frontend-build (push) Successful in 21s
extension / lint (push) Successful in 19s
CI / backend-lint-and-test (push) Successful in 43s
CI / integration (push) Successful in 3m53s
extension/ had no test harness at all -- web-ext lint was the only signal, so
the URL-normalization fix in 8214afe shipped with nothing exercising it.
Adds vitest (mirroring frontend/vitest.config.js) and three specs:
- url.spec.js normalizeApiUrl / webRootFromApiUrl, including the #2393
regression: instance-root input must reach /api/credentials,
idempotence, trailing-slash and whitespace handling, and
that empty input never yields a bare "/api" (which
isConfigured() would read as configured).
- platforms.spec.js getPlatformFromUrl / isArtistPage, pinning the #1485
regression -- all three Patreon creator URL shapes
(bare, /c/, /cw/) plus inner pages, with nav pages
excluded -- and table-integrity checks.
- version.spec.js manifest.json and package.json versions in lockstep,
AMO-safe version format, and url.js ordered before api.js
in background.scripts (classic scripts share one scope, so
a reorder is a runtime ReferenceError with no build signal).
Specs load lib/*.js by evaluating the real file as a classic script
(test/helpers/loadLib.js) instead of adding module.exports shims to production
code that would never run in the browser. The suite therefore exercises exactly
the bytes packaged into the XPI.
Two packaging consequences, both handled:
- web-ext would otherwise bundle test/ and vitest.config.js INTO the XPI;
both are now in --ignore-files across all four web-ext scripts.
- ci.yml's extension-version guard must ignore the same paths, or editing a
spec would demand a pointless version bump. The dangerous drift direction is
the opposite one -- a guard exclusion for a file that DOES ship would let a
real change pass unnoticed -- so version.spec.js asserts every :(exclude) in
ci.yml appears in --ignore-files.
extension.yml also triggers on ci.yml now, since version.spec.js reads it.
Refs #2393, #2397
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
30 lines
1.3 KiB
JavaScript
30 lines
1.3 KiB
JavaScript
import { readFileSync } from 'node:fs'
|
|
import { fileURLToPath } from 'node:url'
|
|
import path from 'node:path'
|
|
|
|
const LIB_DIR = path.join(path.dirname(fileURLToPath(import.meta.url)), '..', '..', 'lib')
|
|
|
|
/**
|
|
* Load an extension lib and hand back the globals it declares.
|
|
*
|
|
* The files under lib/ are CLASSIC scripts, not ES modules: manifest.json
|
|
* lists them in `background.scripts` and options.html pulls them in with a
|
|
* plain <script> tag, so they declare bare functions into a shared scope and
|
|
* export nothing. Rather than bolt a `module.exports` shim onto production
|
|
* code that would never run in the browser, evaluate the real file the same
|
|
* way the browser does — as a script body — and pick the declarations back out.
|
|
*
|
|
* This means the specs exercise the exact bytes that get packaged into the
|
|
* XPI. Only usable for libs that touch no browser APIs at load time
|
|
* (url.js, platforms.js); cookies.js and api.js reference `browser.*` and
|
|
* would need stubbing, which is why they aren't loaded this way.
|
|
*
|
|
* @param {string} filename e.g. 'url.js'
|
|
* @param {string[]} names declarations to return, e.g. ['normalizeApiUrl']
|
|
*/
|
|
export function loadLib(filename, names) {
|
|
const source = readFileSync(path.join(LIB_DIR, filename), 'utf8')
|
|
const factory = new Function(`${source}\nreturn { ${names.join(', ')} }`)
|
|
return factory()
|
|
}
|