diff --git a/guide/package.json b/guide/package.json
index b9798b0200..cc6e1a248d 100644
--- a/guide/package.json
+++ b/guide/package.json
@@ -22,5 +22,8 @@
"clean": "hexo clean",
"test": "npm run clean; npm run build",
"start": "npm run build && chexo @meteorjs/meteor-hexo-config -- server"
+ },
+ "volta": {
+ "node": "14.21.3"
}
}
diff --git a/guide/source/3.0-migration.md b/guide/source/3.0-migration.md
index 6a53fa0c04..4fced532f6 100644
--- a/guide/source/3.0-migration.md
+++ b/guide/source/3.0-migration.md
@@ -3,264 +3,4 @@ title: Migrating to Meteor 3.0
description: How to migrate your application to Meteor 3.0.
---
-> This guide will be created as we approach the Meteor 3.0 release.
-> We're in the process of moving our documentation to Vitepress,
-> and updating the Meteor API docs for version 3.0. For the latest updates,
-> visit https://v3-docs.meteor.com/.
-
-## What's the status of version 3.0?
-
-**Latest version:** `3.0-rc.2`
-**Node.js version:** `20.12.2 LTS`
-**NPM version:** `10.5.0`
-
-Meteor 3.0, currently in its Release Candidate version, is approaching a recommendation for production use. You can check the "[Release 3.0 Pull Request](https://github.com/meteor/meteor/pull/12359)" to see what is being changed.
-
-## How to prepare for version 3.0?
-
-You can follow the guide "[How to migrate to Meteor Async in Meteor 2.x](/prepare-meteor-3.0.html)" to help you prepare your application for the new version by starting to use async methods.
-
-## How to follow the progress on version 3?
-
-The best way to follow the progress is by checking the "[What's left until an official Meteor 3.0?](https://github.com/meteor/meteor/discussions/12865)" discussion. We have also been sharing constant updates on [this topic](https://forums.meteor.com/t/fibers-public-roadmap-and-meteor-3-0/59627/84) in our forum.
-
-## Frequently Asked Questions
-
-### What is Fibers?
-
-Meteor was designed at a time when callback hell was a development issue, so the team decided it at the time
-to use [fibers](https://en.wikipedia.org/wiki/Fiber_(computer_science)) to make building applications much more straightforward with synchronous-looking code.
-The Meteor fibers implementation is based on [node-fibers](https://github.com/laverdet/node-fibers), which is no longer supported as of NodeJS v16.0.0.
-
-The main reason for this migration is to remove the dependency on fibers and make Meteor
-compatible with the latest versions of Node.js.
-
-For more information about fibers, you can check this [talk](https://www.youtube.com/watch?v=bxaOGDqVPKw)
-from Ben Newman and this Stack Overflow [answer](https://stackoverflow.com/a/40865153/6688795).
-
-
-
-### Will MongoDB Collection Methods be removed from the client?
-
-No, we will not remove any MongoDB collection method from the client.
-
-On the client side, all can remain the same. You can use both sync and async methods.
-All should continue working as they are.
-
-For example:
-
-```js
-
-// 2.x in the client side
-
-const docs = MyCollection.find({ _id: '123' }).fetch();
-
-// v3.0 in the client side
-
-const docs = MyCollection.find({ _id: '123' }).fetch();
-
-```
-No changes are necessary. If you want to use the async methods to maintain isomorphic code, you can do it like this:
-
-```js
-
-// 2.x in the client side
-
-const docs = MyCollection.find({ _id: '123' }).fetch();
-
-// v3.0 in the client side, this will work anywhere
-
-const docs = await MyCollection.find({ _id: '123' }).fetchAsync();
-
-```
-
-### Will MongoDB Collection Methods be removed from the server?
-
-Yes, we will remove those MongoDB collection methods that do not end with `*Async`.
-
-You can only use the methods with the `*Async` suffix on the server side.
-
-For example:
-
-```js
-// 2.x in the server side
-
-Meteor.methods({
- myMethod() {
- const doc = MyCollection.findOne({ _id: '123' });
- }
-});
-
-
-// v3.0 in the server side
-
-Meteor.methods({
- async myMethod() {
- const doc = await MyCollection.findOneAsync({ _id: '123' });
- }
-});
-```
-
-Methods that will be _only_ available in the *client* are:
- -`findOne`;
- -`insert`;
- -`remove`;
- -`update`;
- -`upsert`;
-
-If you leave any code using one of these methods in the server side, you will get an error,
-like this one below:
-
-```bash
-findOne is not available on the server. Please use findOneAsync instead.
-```
-
-### How to test Meteor 3.0?
-
-You can create a new Meteor 3.0 project by running the command below:
-
-```bash
-meteor create my-new-project --release 3.0-rc.2
-```
-
-or you can use
-
-```bash
-npx meteor@beta
-```
-it will install the latest beta version of Meteor, please be sure that you are using Node v20 or higher globally.
-
-### How to update from version 2?
-
-You can update your Meteor 2.x project by running the command below inside your project folder:
-
-```bash
-meteor update --release 3.0-rc.2
-meteor reset #resets local DB and project to a fresh state
-```
-
-### When will Meteor 3.0 be ready?
-
-The Release Candidate version has been released. The official version's release will heavily depend on user feedback, but our goal is to release it in Q2 2024.
-
-
-### How do I migrate my package to be compatible with Meteor 3.0?
-
-For the packages that are client only
-or that are do not using Meteor packages that will become async
-or are already using `async` & `await` pattern.
-
-The migration will look like this:
-
-```js
-// in you package.js
-Package.onUse((api) => {
- api.versionsFrom(['1.10', '2.3', '3.0-rc.2']);
- // ^^^^^^^ for testing your package with meteor 3.0
-
- api.versionsFrom(['1.10', '2.3', '3.0']);
- // ^^^^^^^ for meteor 3.0
-
-```
-Then you can publish your package and test it with Meteor 3.0.
-
-If in your package you are using Meteor packages that will become async,
-you will need to migrate your package to use `async` & `await` pattern.
-
-For concrete examples you can check a few examples of packages that have been in the works
-of migrating to Meteor 3.0:
-
-- [`quave:migrations`](https://github.com/quavedev/meteor-migrations/pull/1)
-- [`percolate:synced-cron`](https://github.com/percolatestudio/meteor-synced-cron/pull/149)
-- [`react-meteor-accounts`](https://github.com/meteor/react-packages/commit/96313a1afcc41ef9a23c7496470b375e7d357793)
-- [`mdg:seo`](https://github.com/meteor/galaxy-seo-package/commit/8a30b32688df40e62ce434475dd3ee931dedf2b3)
-
-You can follow a more in depth guide on how to migrate your package to be compatible with Meteor 3.0 [here](/prepare-meteor-3.0#Changes-for-packages).
-
-### When will React packages for Meteor be ready for version 3.0?
-
-We consider React packages to be ready.
-
-It is important to note that migrating your front-end code to async is unnecessary.
-You can still use the sync methods on the client side.
-
-But to maintain isomorphic code, you can use the async methods on the client side.
-
-In those cases, we have implemented `suspense` hooks so that you can use the async methods.
-
-For example:
-
-```js
-
-// you can write like this:
-
-import { useTracker, useSubscribe } from 'meteor/react-meteor-data'
-function Tasks() {
- const isLoading = useSubscribe("tasks");
- const { username } = useTracker(() => Meteor.user())
- const tasksByUser = useTracker(() =>
- TasksCollection.find({username}, { sort: { createdAt: -1 } }).fetch()
- );
-
-
-if (isLoading()) {
- return
-}
-
- // render the tasks
-}
-
-
-// or like this:
-
-import { useTracker, useSubscribe } from 'meteor/react-meteor-data/suspense'
-function Tasks() { // this component will suspend
- useSubscribe("tasks");
- const { username } = useTracker("user", () => Meteor.userAsync())
- const tasksByUser = useTracker("tasksByUser", () =>
- TasksCollection.find({username}, { sort: { createdAt: -1 } }).fetchAsync()
- );
-
-
- // render the tasks
-}
-
-```
-
-`useFind` in the client will remain the same.
-
-You can check the [react-meteor-data docs](https://github.com/meteor/react-packages/tree/master/packages/react-meteor-data) for more information
-and these blog posts [part 1](https://dev.to/grubba/making-promises-suspendable-452f) [part 2](https://dev.to/grubba/new-suspense-hooks-for-meteor-3ddg) for a in-depth look on how we made those changes.
-
-
-### When will Blaze be ready for version 3.0?
-
-The team considered Blaze adjustments to version 3.0 almost done.
-
-It is important to note that migrating your front-end code to async is unnecessary.
-You can still use the sync methods on the client side.
-
-But to maintain isomorphic code, you can use the async methods on the client side.
-
-Since this [PR](https://github.com/meteor/blaze/pull/413) was released with Blaze 2.7. Blaze supports async in their views.
-
-You can check the [Blaze docs](https://www.blazejs.org/api/spacebars#Async-states) for
-more information on how to handle async states.
-
-[@radekmie](https://github.com/radekmie) made two great posts about making Blaze async. Both are worth reading:
- - [On Asynchronicity in Blaze](https://radekmie.dev/blog/on-asynchronicity-in-blaze/);
- - [On Asynchronicity in Blaze (again)](https://radekmie.dev/blog/on-asynchronicity-in-blaze-again/);
-
-
-### When will XYZ package be ready for version 3.0?
-
-Meteor core packages are the responsibility of Meteor Software and are all being migrated.
-If you encounter issues with any of them, let us know, please [open an issue](https://github.com/meteor/meteor/issues/new/choose) in our [repo](https://github.com/meteor/meteor).
-
-This is the [list of all core packages](https://docs.meteor.com/packages/packages-listing.html).
-
-Following the official release of Meteor 3.0, we plan to add new packages to the core and migrating them to Meteor 3.0.
-
-For those packages that are not in the core but are maintained by the [community](https://github.com/Meteor-Community-Packages),
-we hope that the community can work on them, but if for some reason that is not possible,
-you can always ping us on [Slack](https://join.slack.com/t/meteor-community/shared_invite/zt-28aru814j-AwswQGt2D1xIXurvmtJvug) or in the [Forums](https://forums.meteor.com/).
+Please visit [Meteor 3.0 Migration Guide](https://v3-migration-docs.meteor.com/) for our most up-to-date migration guide.
diff --git a/guide/source/prepare-meteor-3.0.md b/guide/source/prepare-meteor-3.0.md
index 402f479dc7..bd0ccccb8b 100644
--- a/guide/source/prepare-meteor-3.0.md
+++ b/guide/source/prepare-meteor-3.0.md
@@ -3,192 +3,4 @@ title: How to migrate to Meteor Async in Meteor 2.x
description: How to migrate your application to async methods and be ready to 3.0.
---
-In the new Meteor 3.0, Meteor moves its methods/operations to asynchronous. In the past, version 2.x was using Fibers, our promise solution, which is no longer supported since Node 16, and to follow the community standards, we are moving to `async` and `await`.
-
-Here are a couple of methods that are now async, and you need to refactor them. Instead of findOne, you need to use the suffix Async, findOneAsync, for example:
-
-Mongo.Collection:
-- findOneAsync
-- insertAsync
-- removeAsync
-- updateAsync
-- upsertAsync
-
-Collection.Cursor:
-- countAsync
-- fetchAsync
-- forEachAsync
-- mapAsync
-
-accounts-base:
-- Meteor.userAsync()
-
-callback-hook:forEachAsync
-- forEachAsync
-
-ddp-server
-- Meteor.callAsync()
-
-The complete list of updated methods is listed [here](https://github.com/meteor/meteor/blob/d5c3b2eeafd0ad78ee7e2553f3f269c5c2a2e2a9/docs/generators/changelog/versions/3.0.md#L5-L17).
-
-If you want to understand better what was changed and the context of Fibers, read these complementary posts:
-- [2.8](https://grubba.medium.com/new-meteor-2-8-and-the-new-mongodb-async-ap-edbcb853869a?source=user_profile---------9----------------------------) _New Meteor 2.8 and the new MongoDB Async API_
-- [2.8.1](https://grubba.medium.com/new-meteor-2-8-1-and-adding-types-to-the-core-8a6ee56f0141?source=user_profile---------7----------------------------) _New MeteorJS 2.8.1 and adding types to the core_
-- [2.9](https://blog.meteor.com/new-meteorjs-2-9-and-the-new-scaffold-api-5fcc0f3b1ce5) _New MeteorJS 2.9 and the new Scaffold API_
-- [2.10](https://blog.meteor.com/new-meteor-js-2-10-and-the-async-tracker-feature-ffdbe817c801) _New Meteor.js 2.10 and the Async Tracker Feature_
-- [2.11](https://grubba.medium.com/new-meteor-2-11-and-the-new-embedded-mongodb-19767076961b?source=user_profile---------4----------------------------) _New Meteor 2.11 and the new embedded MongoDB_
-- [2.12](https://grubba.medium.com/new-meteor-js-2-12-and-the-blaze-2-6-2-release-b72c2a7a593f?source=user_profile---------1----------------------------) _New Meteor.js 2.12 and Blaze 2.6.2 Release_
-- [2.13](https://grubba.medium.com/new-meteor-js-2-13-node-js-14-21-4-security-patch-and-blaze-2-7-1-release-60134947e4c?source=user_profile---------0----------------------------) _New Meteor.js 2.13, Node.js 14.21.4 security patch and Blaze 2.7.1 release_
-
-To help Meteor users update their apps to the new Meteor version, you can follow this guide with some insights on how to do it.
-
-## Use at least Meteor version [2.8](https://blog.meteor.com/new-meteor-2-8-and-the-new-mongodb-async-ap-edbcb853869a)
-
-We recommend starting the async migration by updating your application to 2.8 or newer, as you can do this progressively. Unlike 3.0, you can simultaneously maintain the same codebase with the new asynchronous and old synchronous behaviors. Ideally, you should update to the latest version of Meteor 2.x and carefully follow each changelog. After you refactor all your code to async in version 2.x, you can more easily update it to version 3.0 by following all the changes listed in its [changelog](https://github.com/meteor/meteor/blob/d5c3b2eeafd0ad78ee7e2553f3f269c5c2a2e2a9/docs/generators/changelog/versions/3.0.md).
-
-To help with this update, we suggest you use a [codemod](https://www.sitepoint.com/getting-started-with-codemods/) to automate part of the refactoring process. Follow [this script](https://github.com/minhna/meteor-async-migration) created by [minhna](https://github.com/minhna). The project has documentation explaining how to run the script. This codemod should only affect the server side of your application. Starting the update from the front end or back end is a personal choice. While starting from the server side is a valid approach, it is essential to evaluate whether migrating features one by one might be a better strategy. This way, you can resolve errors incrementally and avoid the risk of encountering multiple client-side issues that could break the entire application.
-
-A helpful feature of the script is that it will refactor some methods to async, such as findOne, count, and other methods from the accounts-base package, such as `Meteor.user()`, and also the function that calls these methods by adding an 'async' before them.
-
-## Edge cases
-Depending on your codebase, the codemod may not work in some specific scenarios. We'll list some edge case examples, and if this is the case for your codebase, you'll need to make the changes manually or refactor the codemod.
-
-### MongoDB methods updates
-A possible edge case is if you are defining your MongoDB collection using the `meteor/quave:collections` package, the codemod will check if it is a MongoDB collection by checking the form of the imports - this means that when the script reads the import coming from ` quave`, it will not consider this to be a MongoDB collection.
-
-### Async functions
-Let's assume your codebase has the same or similar issue listed above. This may imply some problems in refactoring for async functions since the codemod does not correspond to any async method case. This can generate other side effects that imply issues with refactoring forEachAsync, mapAsync, and others.
-
-### How do we identify those edge cases?
-To identify these edge cases, you can use the search feature in your IDE to find your methods and start refactoring by running your refactored codemod or updating the code manually. Since it now only affects the server side, after refactoring, you can run your application, observe the errors that will occur in your terminal, and fix them progressively.
-After refactoring the server side to async, your application will run without errors, and then you can move to the client side.
-
-## Changes for Blaze projects (at least [2.7](https://www.blazejs.org/changelog#v2702023may23))
-In Blaze, every HTML file has a related JavaScript file. After refactoring the JavaScript file to async, you will get a Promise wrapping the value instead of the actual value. To present it on your front end, you must unwrap it. Let's see an example:
-
-```javascript
-{{#let shouldFlag=isFlagged}}
- {{#if @pending 'shouldFlag' }}
-
- {{/if}}
- {{#if @rejected 'shouldFlag' }}
-
- {{/if}}
- {{#if @resolved 'shouldFlag' }}
-
- {{/if}}
-{{/let}}
-```
-
-If you don't unwrap the value, you will get an unresolved promise on the front end. You can use Blaze [Async States](https://www.blazejs.org/api/spacebars#Async-states), which uses the Spacebars Meteor package to handle the promise state. With it, you can handle different states and return appropriate content.
-
-## Changes for React projects
-We recommend installing the package `react-meteor-data`, which contains hooks for these new asynchronous methods. If you use `useFind` on the server side, with SSR, for example, you will need to use the new suspense/useFind hook. We recommend reading the [New Suspense Hooks for Meteor](https://blog.meteor.com/new-suspense-hooks-for-meteor-5391570b3007) article to understand this package better. Example:
-
-```javascript
-const TaskList = () => {
- useSubscribe("tasks");
- const tasks = useTracker('tasks',() => TasksCollection.find({}).fetch());
- return (
-
- {tasks.map((task) => (
-
- ))}
-
- );
-};
-
-export const App = () => {
- return (
-
-
Welcome to Meteor!
- Loading...}>
-
-
-
-
- );
-};
-```
-
-Note that we're not using the if (loading) anymore. To see a practical project, you can check [simpletasks](https://github.com/fredmaiaarantes/simpletasks/), which already use asynchronous API.
-
-If you use `Tracker.autorun()`, for example, reading about the tracker with the [async callback function](https://blog.meteor.com/new-meteor-js-2-10-and-the-async-tracker-feature-ffdbe817c801) is also recommended.
-
-
-## Changes for packages
-
-### Meteor.isFibersDisabled
-
-You can use the [`Meteor.isFibersDisabled`](https://github.com/meteor/meteor/blob/6ac474627a4d2536090484eb95e7c021370aaefe/packages/meteor/asl-helpers-client.js#L1-L8) property to check if the current Meteor version
-is using Fibers or not. In all releases before Meteor 3.0 this property will be `falsy`(`undefined`).
-In Meteor 3.0 this property will be return `true`.
-
-Which means that you can have a code like this:
-
-```js
-
-if (Meteor.isFibersDisabled) {
- // Meteor 3.0
-} else {
- // Meteor 2.x
-}
-
-```
-
-### Changes for packages that are client-only
-
-If your package is client-only, you don't need to worry about the async changes. You can update your package to be compatible with Meteor 3.0 by adding the following line to your `package.js`:
-
-```js
-Package.onUse((api) => {
- api.versionsFrom(['1.10', '2.3', '3.0-alpha.19']);
- // ^^^^^^^ for testing your package with meteor 3.0
-
- api.versionsFrom(['1.10', '2.3', '3.0']);
- // ^^^^^^^ for meteor 3.0
-});
-```
-
-If you want an example of this change, you can take a look at this [commit](https://github.com/meteor/react-packages/commit/96313a1afcc41ef9a23c7496470b375e7d357793)
-where it was made possible for a package to be used in Meteor 3.0.
-
-This change makes sure that your package is still compatible with Meteor 2.x
-and also with Meteor 3.0.
-
-
-### Changes for packages that do not use Meteor packages that had breaking change
-
-Similar to what happens with client-only packages,
-if your package is not using Meteor packages that had breaking changes,
-you can update your package to be compatible with Meteor 3.0
-by adding the following line to your `package.js`:
-
-```js
-Package.onUse((api) => {
- api.versionsFrom(['1.10', '2.3', '3.0-alpha.19']);
- // ^^^^^^^ for testing your package with meteor 3.0
-
- api.versionsFrom(['1.10', '2.3', '3.0']);
- // ^^^^^^^ for meteor 3.0
-});
-```
-
-For example, we have `mdg:seo` where we just needed to add the line above to make it
-compatible with Meteor 3.0.
-You can see the [commit](https://github.com/meteor/galaxy-seo-package/commit/8a30b32688df40e62ce434475dd3ee931dedf2b3).
-
-
-### Changes for packages that are using Meteor API that will become async
-
-In these packages, it will be necessary to refactor and migrate some of its APIs.
-You can be ready for Meteor 3.0 by migrating its API to be async. You can run your tests
-using Meteor 3.0 and ensure everything works as expected.
-
-A good example can be seen here in this [PR](https://github.com/percolatestudio/meteor-synced-cron/pull/149), where we added support for any Meteor version
-beyond v2.8 and also for Meteor 3.0.
-
-
------------
-
-We hope to make your transition easier with these instructions, references, and tools. You may face some challenges, but remember that you can progressively refactor it. For more detailed updates on Meteor 3.0, please check our [Fibers project board](https://github.com/orgs/meteor/projects/10) and the [Meteor 3.0 PR](https://github.com/meteor/meteor/pull/12359).
+Please visit [Migrating to Async in Meteor 2.x](https://v3-migration-docs.meteor.com/migrating-to-async-in-v2/) for more up-to-date information on getting your Meteor 2 application ready for Meteor 3.0.
\ No newline at end of file