Hi! Is there any update? Do you think that we will have a Beta release for this month? I was checking the backlog already but looks like there are a few tasks pending yet for the beta release. Not really sure if it’s just outdated or if the Beta release will be delayed.
Thanks!
Hi, we’re finishing things with our Meteor.callAsync API and that was the main thing holding us back.
Hopefully, this week, we’ll have this finished, and we can move on with the beta.
Hello everyone! Here is a quick update for you on what we’ve been doing in the past few days!
Our Tracker.autorun now has a new attribute called firstRunPromise, and now you can await for the invoice of this method. You can find the PR here, and more details about how to use it in this new blog post.
We’ve also been working with Meteor.callAsync / Meteor.applyAsync API. We needed to make the API easier to use. It wasn’t trivial work, but we’re basically finished with it. The work is divided into two PRs. You can check the first one here and the second one here.
HUGE thanks to our community on this one. We had a lot of feedback and participation on it. And special thanks to @zodern, who created this code. You can check their post about it here.
We also started working on our Migration guide and updating our Docs for version 3.
Unfortunately, we had some drawbacks in the past couple of weeks, but we’re still confident that we can have a Beta version by the end of the year.
So stay tuned, and see you soon for more updates!
You can follow the updates on our overview doc, Fibers Public Roadmap and on this Github PR .
I’ve been out of loop with Meteor for a while, but I see that Tracker now support async functions. But obviously this won’t work with tracker dependencies since the current computation context is lost. What’s the plan to make this work, since this seems quite core to Meteor?
Hey!! It now works! We found a way to make it reactive. It does require a little bit of extra work, but you can maintain the reactive context using Tracker.withComputation function more can be seen in the docs
Also, as a stopgap measure, if you have more complex nested reactive code in the client, you can use our babel plugin to wrap code with Tracker.withComputation automatically and keep the reactive context across async/await calls:
Unless I there’s existing conversation I’ve missed, it seems that the value of native ES modules are being overlooked in the Meteor 3.0 work, and I think it would be crucial to expose a pathway that allows folks to use fully-native JS modules in Meteor 3.0 (for example opting out of ecmascript and modules packages).
I updated the todo list discussion with more details, including links to what I’ve already tried, in this comment: What's left until an official Meteor 3.0? · meteor/meteor · Discussion #12865 · GitHub.
It seems fairly simple, without changing or removing existing ecmascript stuff, to at least enable a pathway to native ES modules.
If you do this, then people will be able to flexibly attach their own build tools to their Meteor workflow without being locked into a system that is already legacy.
Then, a future Meteor 4.0 could delete ecmascript (etc) and provide a better alternative, while at least people on Meteor 3.0 would be able to bypass Meteor’s file handling and simply manage their source code using any of today’s standard tools (or no tools at all, just plain modules).
It seems like the missing piece is an option that enabled import() inside of Node vm instances. Once we have that, we’ll be able to import native ES modules in Meteor (see the links in the comment).
I’ll have a look at this. Maybe get some help from @zodern. I think they would have really good insights on this.
Hello everyone! Here is a quick update on what has happened in the last month!
We launched the first Beta version 
!
You can test by running:
meteor update --release 3.0-beta.0
Meaning that we finished the work with our Meteor.callAsync / Meteor.applyAsync API.
Something worth mentioning again is that this version is already running with Node 20!
Also, we’re working hard to finish migrating and updating our docs and guides. You’ll hear more about it soon.
We’re now moving forward with the Beta, and your help with tests and feedback will be of great value!
So stay tuned, and see you soon for more updates!
You can follow the updates on our overview doc , Fibers Public Roadmap and on this Github PR
Thank you guys, you rock! I can only imagine monumental work behind this. Will check as well, it is about time.
If we limit the scope to only app code on the server, it might not be too much work to add an experimental mode for native ESM. This doesn’t have to be part of Meteor 3. If we make it optional, we can add it in 3.x and iterate on it. There would be many breaking changes with native ESM.
Some of the things involved would be:
Assets requires there to be an app scope, which there wouldn’t be with ESMThe more interesting part is the client. For small apps, using native ESM might work, but the loading time scales with the number of modules, so at some point it becomes too slow. There’s also a number of features missing in ESM that Meteor would be expected or required to have. I’ve been thinking about this for a while. When I find the time, I will write a post describing the details, different options, trade-offs, what other bundlers have done, etc.
Three of the goals we would definitely have are:
I don’t think Meteor’s current module system is that outdated. If we designed a new module system today, it might look very different, or, depending on the goals, features, and the trade offs you were willing to make, you might end up with a very similar design. Some new projects, such as Turbopack or bun, have many similarities with Meteor’s module system. Having said that, I am very interested in alternative designs that have the same benefits of the current system and minimize the issues with it (for example: bundle size, build time complexity, runtime complexity, some core packages unable to use modules). Since we would need the client and server module systems to behave consistently, while experimenting with native ESM would be a good time to explore this.
Before investing in native ESM, it might be good to fix the two main issues with Meteor’s current module system:
I think breaking changes can be avoided. All Meteor APIs are already exposed globally via Package.*. By implementing an ESM customization hook, the Package.* references can simply be exported to the import statements of any native modules.
This will be very similar to what I’ve done with native client-side ESM: my import map simply maps the specifiers to a file that exports stuff from Package.*. (Note, import maps are on the Node.js roadmap as an alternative standards-aligned way to achieve this later).
Customization hooks also allow transpiling content (f.e. they can read a .css file (from the specifier of an import statement), and make the default export be a string containing that CSS, and we can do similar with TypeScript, etc).
File caching would be needed to avoid compilation every single restart if files haven’t changed. A customization hook could also communicate with a dev server that provides cached results.
Here’s the Node’s example on how to begin to add URL imports like Deno: Modules: node:module API | Node.js v21.5.0 Documentation
Here’s a sample of what implementing meteor/foo modules might look like:
// meteor-hooks.mjs
export function load(url, context, nextLoad) {
// Handle 'meteor/*' specifiers
if (url.startsWith('meteor/')) {
const lib = url.split('/')[1] // f.e. "tracker" in "meteor/tracker"
return { format: 'module', source: `export default Package['${lib}']` }
}
// Let Node.js handle all other URLs.
return nextLoad(url);
}
User code for that implementation pattern would need to get the default instead of a named export, and type defs would need to be adjusted, but it would work:
import tracker from 'meteor/tracker'
const {Tracker} = tracker
Alternatively, if we ensure that meteor packages all export the Uppercase name of the package, we can make it a named export:
// meteor-hooks.mjs
export function load(url, context, nextLoad) {
// Handle 'meteor/*' specifiers
if (url.startsWith('meteor/')) {
const lib = url.split('/')[1] // f.e. "tracker" in "meteor/tracker"
const pascalCased = dashToPascalCase(lib) // f.e. tracker to Tracker or foo-bar to FooBar
return { format: 'module', source: `export const ${pascalCased} = Package['${lib}']['${pascalCased}']` }
}
// Let Node.js handle all other URLs.
return nextLoad(url);
}
And then user code would be more like today’s:
import {Tracker} from 'meteor/tracker'
Doing it on native ESM with customization hooks (and/or with import maps later) you won’t have to worry about this. The native module resolution algo will handle that.
No longer resolve hooks (CommonJS), but customization hooks.
That’s a good point. I’ve yet to experience a problem big enough where I needed to bundle my app (with native CommonJS or with native ESM), but it imagine it could certainly be needed.
Bundling would be an optimization for that case, but I think it should be built anew, not based on the ecmascript package, but perhaps on something like esbuild or Vite if not something custom. It will need to support standards like import.meta.url which, when bundled, should not change meaning (console.log(import.meta.url) should log the same both with no bundling or with bundling).
I think the first step will be to get the native ESM mode working, without any such optimizations up front.
Trying to do it all at once will be far too much work, and having a plain ESM mode will already be ideal to begin with: people can start to use their own build tools to target native ESM mode, f.e. compile their own TS to JS, while existing users with existing apps can, for now, continue to use ecmascript and typescript packages.
An initial native ESM mode will usable for new Meteor apps, while existing apps may have migration work to do, but at least it would be a good start until optimzation features come later.
Even starting with no customization hooks, and just global Package for Meteor APIs, and user code as plain ES modules, would be great. Any step that gets us onto on the native ESM path will be great.
It won’t be needed with native ESM, the native loader read exports fields.
ESM, please! It’s 2024!
Hello everyone!
Here is another update on what we’ve been working on in the past few weeks.
We fixed an issue where Symbol.asyncIterator on Cursor was not working. We updated the Reify package inside the core where it wasn’t updated yet. Also worked on issues like: Insert not working for collection created of the fly.
Right now, we are working on:
)We also moved forward with the docs, and it’s looking really good. Here is a sneak peek:
We are planning on releasing a Beta 1 pretty soon, so stay tuned!
You can follow the updates on our overview doc , and on this Github PR
Hello everyone!
Here is one more update.
We release one more Beta, this one being beta.4.
It includes:
for await (const item of Collection.find()));We’re already working on the tasks for the next one, so stay tuned!
You can follow the updates on our overview doc , and on this Github PR.
Hello everyone! If you are still not aware, a few days ago, we released our Beta 6!
You can check more about it here.
Your test and feedback is really important. See you soon!
Hi y’all! Just a quick update.
We’ve been working hard to finish some tasks in the past couple of weeks, and soon (between this week and the next one), we’ll release our last Beta!
After that, we’ll start working on the first RC right away.
Right now, I’m working on this PR, which is really important as it’ll update our skeletons to work with Meteor 3.
We also have this one that we want to fix before releasing this Beta. Then we’ll be ready.
That’s it for now, see you soon!
I just organized the content of the discussion and added estimated release dates for the last Beta and first RC versions.
For those deploying to AWS Node machines (EBS) or those using AWS SDK (such as @aws-sdk/client-s3) after 1 of May, Node 14 is no longer supported. Announcing the end of support for Node.js 14.x in the AWS SDK for JavaScript (v3) | AWS Developer Tools Blog