As otherwise this leads to us importing the tool itself, which has a
top-level function that runs the tool.
As noted on a comment on #42012, this means that the tests are now
executing `gh` which isn't intended.
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
This also makes sure that our URL fragments should be more consistent
over the years, as duplicate names (across parent and child options)
cannot clash.
This also corrects links from the code to include the new fragment.
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* refactor: replace @containerbase/eslint-plugin and eslint-plugin-import-x with local rules and biome
The two containerbase ESLint rules (test-root-describe, no-tools-import) are now
implemented locally in tools/lint/rules.js, removing the external dependency.
All eslint-plugin-import-x rules are dropped: default, named, namespace, and
no-cycle are already covered by oxlint; no-unresolved is covered by TypeScript;
no-extraneous-dependencies is replaced by biome's noUndeclaredDependencies.
* fix: exclude eslint.config.mjs from type-checking
eslint-plugin-promise has no type declarations. Previously this was
masked by @types/eslint pulled in transitively via eslint-plugin-import-x.
The config file is not application code and gains nothing from type-checking.
* refactor: drop eslint-plugin-promise, move covered rules to oxlint
The promise rules target .then()/.catch() patterns which are rare in an
async/await codebase. The 4 rules oxlint supports (catch-or-return,
no-callback-in-promise, no-new-statics, valid-params) are moved there.
* fix: prettier formatting after removing eslint-disable comment
As part of future changes which will fix issues with Composer + Yarn 1
introduced by f430552de4, we need to find
a way to ignore command failure, on a per-command basis.
To do this, we can provide a refactor to introduce a new type,
`CommandWithOptions` which has the ability to specify whether to
`ignoreFailure`.
To make this less of a refactor than would otherwise require, we can
pass around a `(string | CommandWithOptions)[]`
(or a `string[]` or a `CommandWithOptions[]`) to be used, and use
helpers `asRawCommand` and `asRawCommands` to extract the underlying
command where necessary.
In the case a command's failure is being ignored, return the error code
in the `ExecResult`.
We also need to make sure that when executing in Docker, we still
provide the `|| true`s, otherwise we'll start to see commands failing
unexpectedly.
As part of future-proofing the `CommandWithOptions`, we can make sure
that it uses `string[]`s for the command it's representing, to avoid
re-parsing it.
* feat: Cleanup mutexes before each run
* Update setup.ts
* Update mutex.spec.ts
* Update setup.ts
* Unmock mutex in deb datasource spec to prevent race condition
* Update index.spec.ts
* ci: validate all Handlebars helpers are documented
* ci: validate all Handlebars helpers are documented
* chore: validate all handlebars helpers are documented
* chore: validate all handlebars helpers are documented
fix(tests): correctly call `async toMigrate` with vitest
While working on #38240, I noticed that the failing tests I was
writing didn't trigger.
It turns out that in 997c23502e, when we
migrated to Vitest, and made some functions `async`, we missed out on
making the tests themselves `async`.
This correctly applies the `async` modifier to test functions, allowing
them to correctly pass/fail when running async code.
We can also make sure that `toMigrate` is returning a Promise to
indicate it's asynchronous.
Jamie Tanna