⚠️ No Changeset found

Latest commit: 97812e9

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

👋 It looks like the PR template was not used for this pull request.

Please edit the PR description to use the template, or close this PR and open a new one that uses it.
Not using the template may result in your change not being reviewed.

The template includes:

• A Description section
• A Checklist section with items to verify before submitting

Thank you for your contribution! 🙏

• @fast-check/examples

npm i https://pkg.pr.new/@fast-check/ava@6711

npm i https://pkg.pr.new/fast-check@6711

npm i https://pkg.pr.new/@fast-check/jest@6711

npm i https://pkg.pr.new/@fast-check/packaged@6711

npm i https://pkg.pr.new/@fast-check/poisoning@6711

npm i https://pkg.pr.new/@fast-check/vitest@6711

npm i https://pkg.pr.new/@fast-check/worker@6711

commit: d6bd313

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 94.54%. Comparing base (1c68fa1) to head (97812e9).
⚠️ Report is 4 commits behind head on main.

@@           Coverage Diff           @@
##             main    #6711   +/-   ##
=======================================
  Coverage   94.54%   94.54%           
=======================================
  Files         210      210           
  Lines        5686     5686           
  Branches     1499     1500    +1     
=======================================
  Hits         5376     5376           
  Misses        297      297           
  Partials       13       13           

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

@claude review, tell me if things could be said in a better way, improved, made clearer...

Claude finished @dubzzz's task in 55s —— View job

Review of release note for fast-check 4.6.0

• Read the blog post
• Review content and provide feedback

Overall the post is well-structured and covers the three main areas nicely. Here are suggestions to improve clarity and correctness:

Line 7 — Intro paragraph

"without running excessive and costly filtering"

Consider: "without relying on excessive and costly filtering" — filtering isn't "running", it's being relied upon / applied.

Line 17 — "The only limit it relied on was controlled by the notion of size."

This sentence is a bit indirect. Consider: "The only limit was the internal notion of size." — shorter and more direct. You could also link to documentation for size if readers might not know what it means here.

Line 19 — "Unfortunately such call was hurting generation efficiency as it implied throwing away many already generated values."

• Missing comma: "Unfortunately, such a call" (also add article "a").
• "implied" → "required" or "meant" reads more naturally.
• Suggestion: "Unfortunately, such a call hurt generation efficiency as it required throwing away many already-generated values."

Line 27 — Grammar error: "has to falls back"

"the generator still has to falls back to post-filtering"

Should be: "the generator still has to fall back to post-filtering" (bare infinitive after "has to").

Line 27 — "Even with our adapted regex AST trick"

This sentence is dense and does two things at once. Consider splitting:

"Even with this optimization, the generator still falls back to post-filtering to ensure invalid values are never exposed."

The phrase "adapted regex AST trick" is also a bit informal for a release note — "adapted regex AST approach" or "optimization" might read better.

Line 29 — "fast thanks to less post-filtering and smaller values being generated"

"This new flow makes generation of bounded values fast thanks to less post-filtering and smaller values being generated."

Consider: "This approach makes bounded-value generation faster by reducing post-filtering and producing smaller candidate values." — more precise and flows better.

Line 31 — "will result into the regex"

Should be: "will result in the regex" (idiomatic English: "result in", not "result into").

Line 31 — "adapted regex tries to limit as much a possible wrong values"

• Missing "s": "as much as possible"
• The phrasing is awkward. Consider: "the adapted regex significantly reduces the number of invalid values generated."

Line 35 — "from pure Typescript to Rolldown"

"migrates our build pipeline from pure Typescript to Rolldown"

This implies the build pipeline was previously only TypeScript (i.e., tsc). If that's accurate, great. But if it used other tools too (e.g., rollup), it might be worth being more precise: "from the TypeScript compiler to Rolldown" or "from tsc to Rolldown".

Also: "Typescript" → "TypeScript" (capital S, matching the official branding).

Line 35 — "We also benefit from the same improvements from our underlying random number generator library"

"the same improvements" is ambiguous — same as what? Consider: "We also benefit from improvements in our underlying random number generator library, pure-rand, by upgrading to its latest major version." — naming the library helps readers who might want to look it up.

Line 37 — "It also cut the file count"

Tense mismatch: the previous sentence uses "reduce" (present tense). Should be "It also cuts the file count" or change both to past tense: "reduced … cut".

Line 39 — Import speed section

"On our side we measured import speed improvements ranging from 1.75x to 2.35x faster"

• Add comma: "On our side, we measured…"
• "1.75x to 2.35x faster" — Consider whether "1.75× to 2.35× faster" (with ×) or just "1.75× to 2.35×" is clearer. Saying "2.35x faster" could be interpreted as "the old time + 2.35× the old time". If you mean the import is 2.35× as fast (i.e., takes ~42% of the old time), you might say: "import times improved by 1.75× to 2.35×".

Line 43 — "The method Random::next(n) and the no-argument Random::nextInt() have been marked as deprecated."

This reads well. Minor: since this is TypeScript/JS, the :: notation is unusual — readers might expect Random.next(n) or Random#next(n). If you're deliberately using :: as a convention, that's fine, but it might confuse some readers.

Line 45 — "On the long run"

Should be: "In the long run" (idiomatic English).

Line 45 — "we probably plan to deprecate"

"Probably plan" is hedging twice. Pick one: "we plan to eventually deprecate" or "we will probably deprecate".

Line 45 — "By doing so we hope dropping one unneeded indirection to have faster random values generation and we also want to let user decide on the distribution they want to raise in their arbitraries."

This is a long sentence trying to convey two distinct benefits. Suggestions:

• "By doing so, we hope to drop" (missing "to")
• "let users decide" (plural)
• "the distribution they want to use" — "raise" is unusual in this context
• Consider splitting: "By doing so, we hope to remove an unnecessary indirection layer for faster random value generation. We also want to let users choose the distribution they use in their arbitraries."

Summary

The content is solid and informative. The main areas for improvement are:

1. Grammar fixes: "has to falls back", "result into", "as much a possible", "On the long run", "Typescript"
2. Clarity: A few sentences are dense or ambiguous — splitting them and being more specific (naming pure-rand, clarifying "the same improvements") would help
3. Consistency: Watch for tense shifts (present vs. past) within the same section
4. Minor style: "probably plan" double-hedges; "raise" is unusual for distributions; :: notation may confuse JS/TS readers

None of these are blocking — the post clearly communicates the key improvements in 4.6.0.
|

@claude open a new PR on top of this one with all your suggestions

Claude finished @dubzzz's task in 2m 0s —— View job

Applying review suggestions to a new PR

• Read the blog post file
• Apply all grammar and clarity fixes
• Create a new branch and open a PR

All review suggestions have been applied in #6719 (targeting this branch).

Changes applied:

• "without running" → "without relying on"
• Simplified "The only limit it relied on was controlled by the notion of size" → "The only limit was the internal notion of size"
• Added missing commas and articles; "implied" → "required"; "already generated" → "already-generated"
• Fixed "has to falls back" → "falls back"; simplified the sentence
• "This new flow makes generation of bounded values fast thanks to…" → "This approach makes bounded-value generation faster by…"
• "result into" → "result in"; "as much a possible wrong values" → clearer phrasing
• "pure Typescript" → "the TypeScript compiler"; named pure-rand explicitly with link
• "cut" → "cuts" (tense consistency)
• "1.75x to 2.35x faster" → "1.75× to 2.35×" (clearer multiplier notation)
• "On the long run, we probably plan" → "In the long run, we plan to eventually"
• Split dense final sentence into two clear sentences; "raise" → "use"; "user" → "users"
  ·

@copilot rename the file to match the 9th march

@dubzzz I've opened a new pull request, #6720, to work on those changes. Once the pull request is ready, I'll request review from you.

@copilot rename the file to match the 9th march

@dubzzz I've opened a new pull request, #6721, to work on those changes. Once the pull request is ready, I'll request review from you.