* test: replace manual process.env mutation with vi.stubEnv
Enable Vitest's `unstubEnvs` so env stubs are reverted automatically
before every test, and convert the manual `process.env.X = ...` /
`delete process.env.X` pairs in specs to `vi.stubEnv()`.
This removes the hand-written `afterEach` cleanup blocks and the
`const OLD_ENV = process.env` / `process.env = { ...OLD_ENV }`
save-restore dance, which silently leaked state between tests when a
test set a variable without a matching delete.
Left as-is (incompatible with `unstubEnvs`, which unstubs before each
test, not after):
- module top-level env writes (cocoapods, gomod, post-update, pip-compile
and bundler artifacts specs)
- `beforeAll` env writes -- the two in `util/http` moved to `beforeEach`
* test: stop asserting on ambient environment variables
Three specs asserted on values that the surrounding environment can
override, so they only passed on a machine that happened not to set them:
- `util/exec/env`: `getChildProcessEnv()` forwards every entry of
`basicEnvVars`, but the spec only seeded a subset. Any other forwarded
variable that was set ambiently (e.g. a lowercase `http_proxy`) leaked
into the `toEqual` assertion. Clear all of them first.
- `util/git/index`: `process.env.GIT_SSH_COMMAND` deliberately overrides
the default that the two env-inheritance tests assert on. Clear it.
- `logger/pretty-stdout`: the colorized level strings are built at import
time, so the `beforeEach` setting `FORCE_COLOR` could never affect them
-- it was dead code, and the test silently assumed a terminal without
colour support. Derive the expectation the same way the module does.
* test(datasource/nuget): use a throwaway cache dir for nupkg downloads
The `determine source URL from nupkg` tests do not mock the filesystem,
so they really wrote downloaded packages into a fixed `/tmp/cache` path.
That fails wherever the system tmpdir is not writable, and two checkouts
running the suite at once would share the same directory.
Use `tmp.dir({ unsafeCleanup: true })` and clean it up afterwards, which
is the pattern the other specs that touch disk already use.
* feat(lint): add renovate/prefer-stub-env rule
Enforces in specs what the migration to `vi.stubEnv` established:
- assigning to or deleting `process.env.X` inside `beforeEach`, `afterEach`,
`it` or `test` is reported, with a fixer that rewrites it to `vi.stubEnv()`
- module scope, `describe` bodies and `beforeAll` / `afterAll` are left alone:
`unstubEnvs` reverts stubs *before* each test, so a stub created there is
gone by the time the first test runs, and those must keep assigning directly
- replacing the `process.env` object is reported everywhere and never fixed.
`vi.stubEnv()` captures the original object when the worker starts, so after
a reassignment its deletes silently target the old object
The rule found 28 further violations in specs the earlier sweep missed, since
that one was anchored on `delete process.env`. Twelve were auto-fixed; the
rest replaced `process.env` wholesale and are now `clearEnv()` from test/util.
`util/exec/index.spec.ts` opts out with a comment: it asserts on the whole
child env, and `vi.stubEnv()` cannot express that because it maps `PROD`,
`DEV` and `SSR` onto '' instead of deleting them.
* fix(http): fallback to github hostType for GHE platform endpoint
When running against GitHub Enterprise Server, datasources not listed
in GITHUB_API_USING_HOST_TYPES (e.g. github-digest) fail to authenticate
because the existing fallback only covers api.github.com URLs.
This adds a host-matching fallback: when the active platform is github
and the request URL targets the same host as the configured endpoint,
credentials from the github hostType rule are applied.
* Refactor
* Fix
feat(hostRules): automagically use host rules for any `api.github.com` lookups
As noted in #38732, the Typst datasource performs API calls to the
GitHub APIs, but as we do not have explicit datasource mapping for the
API calls (via `GITHUB_API_USING_HOST_TYPES`), we end up sending
unauthenticated API calls, which then can result in rate limits.
We had previously attempted to fix this in #30490, for a different
datasource, and there are likely other datasources impacted.
To simplify this, we can auto-wire any `https://api.github.com/` API
calls with the `hostType: github` hostRule, when matching against the
hostname from the `url`.
This also adds a note to deprecate the usage of
`GITHUB_API_USING_HOST_TYPES`, unless it's explicitly needed.
Closes#38953.
As part of #38953, we are changing the way that host rules work for
GitHub.com, and automagically wiring them in for datasources that
interact with `github.com`.
To do this, we should first provide a clearer definition of how host
rules should work, especially when there may be conflicting sources of
tokens, or where we may be on GitHub Enterprise Server vs GitHub.com.
Sebastian Poxhofer