[code-infra] Add cli to extract error codes independent of build

[brijeshb42]

This exposes a cli command extract-error-codes to extract annotated errors from workspace packages. This makes the error code extraction independent of the build process. The command is supposed to work on the whole workspace instead of at the individual package level (unless we have a use case later).
There's a way to make this even faster by just processing the files that have changed in this branch instead of all the files in all the packages. But the current gains are already huge and using git would be a micro-optimization. We could revisit this in future.

Also created a helper wrapInWorker function to abstract creation of worker pools and migrated code to use it.

Closes #580

Repo PRs -

1. [code-infra] Make error code extraction independent of build material-ui#46865
2. [code-infra] Migrate error code extraction to code-infra base-ui#2670

[mui-bot]

Bundle size report

Bundle	Parsed size	Gzip size
@base-ui-components/react	0B(0.00%)	0B(0.00%)

Details of bundle changes

[Janpot]

Suggestion to simplify this helper a bit:

async function mapConcurrently<T, R>(items: T[], mapper: (t: T) => Promise<R>, concurrency: number): Promise<R[]>

• Make the signature more like a map operation, allow returning results, to satisfy more use-cases.
• Remove the promiseMethod, this can just be done in the mapper by the consumer. We can avoid leaking the implementation this way.
• Make concurrency explicitly required, avoid consumers to rely on a arbitrary default.

[Janpot]

Seems like allSettled wasn't wanted here, the JSON.parse is already wrapped, and the fs.readFile we would want to propagate its errors.

[brijeshb42]

My thinking was that we'd want to know about all the erroneous json files in the same run instead of just failing on the first wrong file.
This way, devs can fix the files together instead of running the command multiple times.

[Janpot]

That would still work, the JSON.parse is wrapped in try/catch already, and the catch just logs. as far as I can see, the allSettled is not doing anything, except from hiding errors from fs.readFile, which is undesired.

[brijeshb42]

Yeah. I figured later. Removed the option.

[Janpot]

Poor man's tracer 😄 . Suggestion: could be more versatile if we maintain return value of the function, and instead

async function markFn<F extends Function>(label: string, fn: (...args: Parameters<F>)): Awaitable<ReturnValue<F>>;
// and
async function measureFn(label: string)

// then use as

const result = await markFn('foo', async () => {
  return // ...
});

console.log(`It took ${measureFn('foo').duration}ms to calculate ${result}`)

[brijeshb42]

Calling markFn('foo',...) and then again measureFn('foo') seems repititive. Should be another way to do both in the same call.

[Janpot]

It's sort of repetitive, but ideally we make it so we can wrap existing code with measureFn, including code that returns values. I think it would be nice to just simply complement the performance.mark and performance.measure functions with functions that can automatically wrap and keep the same API philosophy of being able to just insert some function calls without semantically having to change the program.

Doesn't matter much, not a blocker for this PR at all

[Janpot]

Would it make sense to determine the full list of files across all packages, and then run the extractor concurrently over that? Otherwise we multiply the concurrency with each specified package. i.e. 1 package => concurrency 30, 3 packages => concurrency becomes 90. So we then would have concurrency of 90, but it wouldn't be fully used all the time if there's e.g. an asymmetrically large package in there.

[brijeshb42]

Yeah. That's better. I was working on the pretext of packages but your suggestion makes sense.

[Janpot]

Love this, made a few suggestions, but no blockers for me.

[Janpot]

👌