Ryan Ling

Anecdotally we seem to have been hit by this once upgrading to `6.0.0`; likely arbitrary length unions and the like contribute another layer of depth.

I'm guessing this would equally make sense for `skuba lint`

I'd also note that we haven't provided an obvious way to use `skuba lint` in a monorepo today: - Running it at the root requires `tsconfig.json` fiddling at different subdirectory...

This may be improved by ESLint flat config: seek-oss/skuba#1157

🤔 I'm not seeing this error with a minimal configuration of: .buildkite/pipeline.yml ```yaml steps: - agents: queue: xxx command: yarn test env: DOCKER_BUILDKIT: 1 plugins: - seek-oss/docker-ecr-cache#v1.1.6: cache-on: yarn.lock -...

I think one minor challenge is the package is private, so our integration test will need an npm read token

Sorry for leaving this so long! Yep, we've moved on to Vanilla Extract. A deprecation message has been added to the package and README.

I think I could be convinced to do this once we land #1289; I'd have concerns around depending that heavily on the Yarn mirror to rebuild in a DR scenario...

That's a good point to clarify, what #817 does is move `plugins` anchors inline at the first point of declaration and switch `base-steps` out for `matrix`.

Looks like switching to the official signed pipeline implementation may let us use `mount-buildkite-agent: true` instead of having to resort to volume mounting: https://github.com/seek-oss/skuba/blob/9cf258b0f2190ed5de32abd313a0417e9cdf32ae/docs/deep-dives/buildkite.md?plain=1#L35-L37