docs: blog post v9.0 #3056
docs: blog post v9.0 #3056
Conversation
✅ Deploy Preview for fakerjs ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
xDivisionByZerox
added
c: docs
|
You need to add a link here faker/docs/.vitepress/config.ts Lines 62 to 65 in 0fd0402 |
| # What's New In v9.0 | ||
|
|
||
| ::: info Looking for the migration guide? | ||
| This article is a focusing on changes happened in the development of v9 that are on the more interesting side. |
There was a problem hiding this comment.
This article is a focusing on...
Should be
This article focuses on...
There was a problem hiding this comment.
There are even more grammatical issues, so maybe just paste the blog into another spellchecking tool and fix them with one commit
|
|
||
| ## Optimizing Bundle Size with Tree-Shaking | ||
|
|
||
| In the upcoming release of Faker.js, we’ve tackled an important issue related to bundle size. The problem? Unnecessary modules were being included during tree-shaking, leading to bloated final bundles. But fear not! We’ve got a solution. |
There was a problem hiding this comment.
IMO we should not refer to upcoming release, as the blog will either be merged either right before the major release or afterwards.
| @@ -60,50 +60,10 @@ While this is not a breaking change according to semantic versioning guidelines, | |||
|
|
|||
| ### Use High Precision RNG by Default | |||
|
|
|||
| TLDR: Many Faker methods return a different result in v9 compared to v8 for the same seed. | |||
|
|
|||
| In v9 we switch from a 32 bit random value to a 53 bit random value. | |||
| We don't change the underlying algorithm much, but we now consume two seed values each step instead of one. | |||
There was a problem hiding this comment.
Add a link to the relevant section in the announcement blog.
There was a problem hiding this comment.
This should have a link to the announcement blog page
| ## More Localized Data | ||
|
|
| 1. [Create a release Pull Request](https://github.com/faker-js/faker/pull/2981) | ||
| 1. [Have an additional CI suite that tests against our playground](https://github.com/faker-js/faker/pull/2988) | ||
| 1. [Create a GitHub Release](https://github.com/faker-js/faker/pull/2990) | ||
| 1. [Release the latest version to npm](https://github.com/faker-js/faker/pull/2991) |
There was a problem hiding this comment.
Can we number these correctly even if GH/vitepress fixes them automatically?
|
|
||
| 1. [Create a release Pull Request](https://github.com/faker-js/faker/pull/2981) | ||
| 1. [Have an additional CI suite that tests against our playground](https://github.com/faker-js/faker/pull/2988) | ||
| 1. [Create a GitHub Release](https://github.com/faker-js/faker/pull/2990) |
There was a problem hiding this comment.
IMO we should refer to this as Draft a GitHub release
| 1. [Create a release Pull Request](https://github.com/faker-js/faker/pull/2981) | ||
| 1. [Have an additional CI suite that tests against our playground](https://github.com/faker-js/faker/pull/2988) | ||
| 1. [Create a GitHub Release](https://github.com/faker-js/faker/pull/2990) | ||
| 1. [Release the latest version to npm](https://github.com/faker-js/faker/pull/2991) |
There was a problem hiding this comment.
IMO we should refer to this step as Publish the ...
| This allows us to kick off the process with a single manual schedule of the PR creation job. | ||
| This PR will then run an additional test CI (in parallel to our normal one) against our [playground repo](https://github.com/faker-js/playground). | ||
| If the PR is successfully merged another job is automatically started to create a draft GitHub Release. | ||
| This allows us to verify the correctness of the release one last time. |
There was a problem hiding this comment.
IMO this isn't the main point of that step, IMO it just gives us the ability to edit the GitHub release to our needs.
But I'm not sure whether that is nitpicking or not.
| If the PR is successfully merged another job is automatically started to create a draft GitHub Release. | ||
| This allows us to verify the correctness of the release one last time. | ||
| By publishing the GitHub release, the last job will kick in to publish this release to npm. | ||
| All these steps where done manually by the maintainers, previously. |
There was a problem hiding this comment.
Maybe add a little bit of "why" here aka "and sometimes we forgot them or did them in the wrong order"
WIP