@yslpn is attempting to deploy a commit to the Crowdin Team on Vercel.

A member of the Team first needs to authorize it.

Codecov Report

❌ Patch coverage is 68.62745% with 16 lines in your changes missing coverage. Please review.
✅ Project coverage is 88.00%. Comparing base (dd43fb0) to head (50c4ee3).
⚠️ Report is 291 commits behind head on next.

❌ Your patch status has failed because the patch coverage (68.62%) is below the target coverage (70.00%). You can increase the patch coverage or adjust the target coverage.

@@             Coverage Diff             @@
##             next    #2420       +/-   ##
===========================================
+ Coverage   76.66%   88.00%   +11.33%     
===========================================
  Files          81      113       +32     
  Lines        2083     3301     +1218     
  Branches      532      965      +433     
===========================================
+ Hits         1597     2905     +1308     
+ Misses        375      356       -19     
+ Partials      111       40       -71     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

I pushed some slight changes in types, just wanted to have call to pool.run(...args) look more like a method execution with argument instead passing args as array/tuple.

Also i'm wondering about:

minThreads: poolSize,
maxThreads: poolSize,

Probably we should set only a maxThreads, so if there would be only 2 tasks, and poolSize = 5, it will not spawn 3 extra workers.

It's better to consult actually what their docs saying about best practicies and maybe check vitest code how they works with those parameters.

I pushed some slight changes in types, just wanted to have call to pool.run(...args) look more like a method execution with argument instead passing args as array/tuple.

Thanks

Also i'm wondering about:

minThreads: poolSize,
maxThreads: poolSize,

Probably we should set only a maxThreads, so if there would be only 2 tasks, and poolSize = 5, it will not spawn 3 extra workers.

It's better to consult actually what their docs saying about best practicies and maybe check vitest code how they works with those parameters.

I found that vitest was removed from vitest and they wrote their own implementation https://vitest.dev/guide/migration.html#pool-rework

I looked at how facebook/docusaurus uses it; they also use the same values ​​for maxThreads and minThreads. They calculate the ideal number for themselves based on pages:
https://github.com/facebook/docusaurus/blob/df259ddb269153e652f3731ab5cd52d12244b45f/packages/docusaurus/src/ssg/ssgExecutor.ts#L126

50 pages → 1 thread
150 pages → 2 threads
and so on.

In our case, we have two options:
ref: https://lingui.dev/ref/cli#extract-workers

1. We calculate the number of threads ourselves, before starting, using --workers
   To avoid breaking the cli API and creating new flags, we can leave the same number of threads specified with --workers, and we guarantee this number of threads.

minThreads: poolSize,
maxThreads: poolSize,

2. Or we calculate automatically.
   Use our current logic for calculating the number of threads and pass this value to maxThreads.

minThreads: 0,
maxThreads: poolSize,

Plus, we need to adjust all the messages, as there will be two cases:

Use worker pool of size ${poolSize} and Use worker pool with up to ${poolSize} workers

Is that okay?

It seems from the docs (from upstream piscina):

minThreads: (number) Sets the minimum number of threads that are always running for this thread pool. The default is the number provided by os.availableParallelism.
maxThreads: (number) Sets the maximum number of threads that are running for this thread pool. The default is the number provided by os.availableParallelism * 1.5.

That minThreads is not based on the number of tasks. So i'm confused now how that works. Reading this docs seems your's

minThreads: poolSize,
maxThreads: poolSize,

totally makes sense

@andrii-bodnar regarding coverage - disregard this report, since workers are not instrumented by covergae because they run in kinda separate process. The functionality is covered in the original implementation - this change doesn't add anything to logic we already have.