These are some items I would be interested in that haven’t already been listed:
Compatibility tables / support docs
It would be nice to have someplace we can easily check:
- which versions of the MongoDB server a release of Meteor supports
- browser support
- which ECMAScript version is fully supported in all arch’s. Currently, it’s not always clear if a feature we can use in modern browsers would also be supported in legacy browsers.
- compatibility for build plugins and core packages commonly used by build plugins. Build plugins are are unique in that they are built when published and bundle a copy of their deps, so which Meteor version you publish a build plugin with affects which older Meteor versions it can run in.
- which Node and npm version are used by each Meteor release
More thorough docs
It’s improved the last couple years, but there are still many things that are undocumented. It would be nice if someone would go through the change log at least as far back as Meteor 1.3, and the issues from the old docs repo including those that were closed for being old, and add anything missing. Another thing that would be nice is going through the docs, migration guides, and tutorials and improving the language. There are many sections with poor grammar or that explain things in a more complicated and unclear way than necessary.
Security Updates
Currently, Meteor only consistently provides security updates for the latest release. This makes it difficult for companies that are a version or two behind since they have to rush to update to the latest release before they were planning to, and sometimes run into undocumented breaking changes or bugs that make it difficult or impossible to update. I know companies that migrated away from Meteor because it was too difficult for them to stay on a Meteor release that had a node version with the latest security patches.
Also, sometimes that are delays of up to several weeks before there is a new Meteor release after there is a new node version with a fix for a security issue.
It would be nice if Meteor in some form committed to providing security updates in a way that addresses these issues.
npm installer improvements
When I created the npm installer, I tried to make it work with as wide range of node version as I reasonably could to make it easier to install Meteor. However, now it only works with a limited range of node versions, none of which are still supported by Node which makes installing Meteor more difficult. There are also a few issues open documenting long standing issues with the installer.
Windows for a while now comes with a native tar, so it would be good to use that instead of 7zip when available. This would make the installer smaller, and Windows Defender has some exceptions for the native tar which should make Meteor faster to install.
Remove ECMAScript.compileForShell
This could maybe be done by moving the function to the babel-compiler package, or moving the code to the one place it is used. This function causes every build plugin and app that uses the ecmascript package to have a full copy of the babel-compiler package, in addition to every Meteor release. A few years ago, I found that half the disk usage (I think half was ~5gb) in ~/.meteor was just copies of babel-compiler, and it was also a large reason installing Meteor was so slow on Windows.
Isobuild
Linker rewrite
This is probably one of the next things I will work on. The linker in Meteor is far behind the state of the art in terms of performance. Linkers in js bundlers have always been slow, and Meteor is missing many of the improvements other bundlers have implemented the past few years. It might even be possible to remove the disk cache, which causes its own performance issues.
Fully enable in-place builds on Windows
On Windows it is still disabled for client only builds, which for large apps can cause client only rebuilds to be significantly slower than full rebuilds. A couple years ago I finally figured out how we can safely fix this, so I or someone else just needs to spend the time to implement and test it.
Recursive file watchers on all platforms
We switched to using recursive file watchers on Windows and macOS, which is more efficient and detects file changes much quicker than how Meteor previously worked. Linux doesn’t support recursive file watchers, and the implementation used in most libraries would have created too many file watchers so it still uses the old file watching implementation. Recently @parcel/watcher added some features that would allow us to switch to it and use it on all platforms
We should also look into reducing the number of files Meteor watches. There are some folders Meteor considers as immutable, so Meteor only needs a single watcher for each of those.
Replace LRU cache
Many of the performance issues in Meteor the last few years have been from LRU caches not being configured large enough. However, constantly increasing the size of the caches will allow Meteor to use more memory than necessary for smaller apps. We should look into building a custom in-memory cache implantation that tracks which entries are needed and which can be freed so we don’t have to set an arbitrary size for each cache.
Rewrite the js-analyze code to use SWC
This part of isobuild handles scanning for imports and for globals, and over the last couple years it has become a performance issue. This would be a good place to experiment with using rust and/or wasm to speed up parts of the build process.
Switch back to using native tar
I don’t really understand the reason for Meteor switching away from it, but it seems like at some point there was a Meteor release that broke permissions in tar files created on Windows, so Meteor switched to using a js tar implementation that allows Meteor to fix the permissions when extracting the tar file on linux/macOS. Recently I found that the js tar implementation is significantly slower, and makes downloading a Meteor release or Meteor packages up to 2 - 3 times slower. It would be worth reviewing this and finding a way to switch back to using native tar.
noticed that the last few years, there hasn’t been as much public information on the reason for changes compared to before. The detailed PR’s and commit messages that Meteor had for many years is what allowed me to understand how and why Meteor worked the way it did and to start contributing to it.
Regarding switching to vite, I’m not sure that is the best path forward. Each bundler makes very different trade offs, and vite and isobuild are very different. A recent example is top level await. Having async code in the root of modules was very common with fibers, so we spent a lot of effort into creating a spec-compliant implementation for Meteor. In comparison, vite uses a different implementation in development and production, and the production implementation behaves differently and is not spec compliant.
It seems that the two main things missing from Meteor, besides features that we can add, are:
- performance
- vite has a larger ecosystem, at least in part to having better support for build plugins
For performance, I have a long list of things we can improve before we even need to think about a new architecture. Its been a few years since we’ve had a release focused on build performance.
For build plugins, it is surprisingly difficult to create a build plugin for Meteor - there are many bugs and it is difficult to create a well working plugin, and there is very little documentation. Besides that, Meteor’s current design for build plugins is from Meteor 1.2, and I’m not confident that being designed around batching has aged well. It probably is time to design a new, simplified build plugin api.
