Seeking Community Input: Meteor.js Roadmap

[msavin]

Yes I’ve been looking at the package a lot but it says tested with Meteor 2.5.x and it’s using the deprecated phonegap push plugin. Part of why I like to use Meteor is that for the most part, everything is supported and backwards-compatible with new releases.

I’ve been trying to implement my own version of it, but keep getting weird errors like this endlessly:

/Users/max/Documents/GitHub/ninjalerts_react/.meteor/local/cordova-build/platforms/ios/Pods/Pods.xcodeproj: warning: The iOS Simulator deployment target 'IPHONEOS_DEPLOYMENT_TARGET' is set to 8.0, but the range of supported deployment target versions is 11.0 to 16.4.99. (in target 'nanopb' from project 'Pods')
warning: Run script build phase 'Copy www directory' will be run during every build because it does not specify any outputs. To address this warning, either add output dependencies to the script phase, or configure it to run in every build by unchecking "Based on dependency analysis" in the script phase. (in target 'ninjalerts_react' from project 'ninjalerts_react')
/Users/max/Documents/GitHub/ninjalerts_react/.meteor/local/cordova-build/platforms/ios/Pods/Pods.xcodeproj: warning: The iOS Simulator deployment target 'IPHONEOS_DEPLOYMENT_TARGET' is set to 10.0, but the range of supported deployment target versions is 11.0 to 16.4.99. (in target 'Protobuf' from project 'Pods')
/Users/max/Documents/GitHub/ninjalerts_react/.meteor/local/cordova-build/platforms/ios/Pods/Pods.xcodeproj: warning: The iOS Simulator deployment target 'IPHONEOS_DEPLOYMENT_TARGET' is set to 9.0, but the range of supported deployment target versions is 11.0 to 16.4.99. (in target 'PromisesObjC' from project 'Pods')
warning: Run script build phase 'Create Symlinks to Header Folders' will be run during every build because it does not specify any outputs. To address this warning, either add output dependencies to the script phase, or configure it to run in every build by unchecking "Based on dependency analysis" in the script phase. (in target 'PromisesObjC' from project 'Pods')
/Users/max/Documents/GitHub/ninjalerts_react/.meteor/local/cordova-build/platforms/ios/Pods/Pods.xcodeproj: warning: The iOS Simulator deployment target 'IPHONEOS_DEPLOYMENT_TARGET' is set to 8.0, but the range of supported deployment target versions is 11.0 to 16.4.99. (in target 'GoogleUtilities' from project 'Pods')
/Users/max/Documents/GitHub/ninjalerts_react/.meteor/local/cordova-build/platforms/ios/Pods/Pods.xcodeproj: warning: The iOS Simulator deployment target 'IPHONEOS_DEPLOYMENT_TARGET' is set to 8.0, but the range of supported deployment target versions is 11.0 to 16.4.99. (in target 'GoogleDataTransport' from project 'Pods')
/Users/max/Documents/GitHub/ninjalerts_react/.meteor/local/cordova-build/platforms/ios/Pods/Pods.xcodeproj: warning: The iOS Simulator deployment target 'IPHONEOS_DEPLOYMENT_TARGET' is set to 8.0, but the range of supported deployment target versions is 11.0 to 16.4.99. (in target 'FirebaseMessaging' from project 'Pods')
/Users/max/Documents/GitHub/ninjalerts_react/.meteor/local/cordova-build/platforms/ios/Pods/Pods.xcodeproj: warning: The iOS Simulator deployment target 'IPHONEOS_DEPLOYMENT_TARGET' is set to 8.0, but the range of supported deployment target versions is 11.0 to 16.4.99. (in target 'FirebaseInstanceID' from project 'Pods')
/Users/max/Documents/GitHub/ninjalerts_react/.meteor/local/cordova-build/platforms/ios/Pods/Pods.xcodeproj: warning: The iOS Simulator deployment target 'IPHONEOS_DEPLOYMENT_TARGET' is set to 8.0, but the range of supported deployment target versions is 11.0 to 16.4.99. (in target 'FirebaseInstallations' from project 'Pods')
/Users/max/Documents/GitHub/ninjalerts_react/.meteor/local/cordova-build/platforms/ios/Pods/Pods.xcodeproj: warning: The iOS Simulator deployment target 'IPHONEOS_DEPLOYMENT_TARGET' is set to 8.0, but the range of supported deployment target versions is 11.0 to 16.4.99. (in target 'FirebaseCoreDiagnostics' from project 'Pods')
/Users/max/Documents/GitHub/ninjalerts_react/.meteor/local/cordova-build/platforms/ios/Pods/Pods.xcodeproj: warning: The iOS Simulator deployment target 'IPHONEOS_DEPLOYMENT_TARGET' is set to 8.0, but the range of supported deployment target versions is 11.0 to 16.4.99. (in target 'FirebaseCore' from project 'Pods')
/Users/max/Documents/GitHub/ninjalerts_react/.meteor/local/cordova-build/platforms/ios/Pods/Pods.xcodeproj: warning: The iOS Simulator deployment target 'IPHONEOS_DEPLOYMENT_TARGET' is set to 8.0, but the range of supported deployment target versions is 11.0 to 16.4.99. (in target 'Firebase' from project 'Pods')

You cannot know where people are signed in because this is between your hardware and the FCM.

So what I’m doing here is tracking the loginToken, since that is also unique to the hardware. If a user signs out via token expiration, terminating all login sessions, etc, it would be bad if they keep getting push notifications that may contain personal data.

Maybe - maybe - this goes into a feature where you can store data on the login token session. This can be done manually but could be a nice vendor supported feature, with hooks like onLoginTokenCreation, onLoginTokenTermination, setLoginSessionConfig, etc.

[paulishca]

You can call unregister anywhere on the client.

unregister () {
    isSupported().then(supported => {
      if (supported) {
        let Messaging
        if (this.push) {
          Messaging = this.push
        } else {
          const webApp = initializeApp(webPush.firebase)
          Messaging = getMessaging(webApp)
        }
        deleteToken(Messaging)
          .then(() => {
            Meteor.callAsync('token-remove', { _id: deviceStorage.getItem('Push.tokenId'), token: { vendor: 'web', token: deviceStorage.getItem('Push.token') } })
              .then(res => {
                // console.log('Found tokens and deleted: ', res)
                deviceStorage.removeItem('Push.token')
                deviceStorage.removeItem('Push.tokenId')
              })
              .catch(err => console.log('Could not delete this token from DB: ', err))
          })
      } else {
        return () => {}
      }
    })
  }

Ok the unpublished package is based on this plugin: @havesource/cordova-plugin-push.

Cordova.depends({
  '@havesource/cordova-plugin-push': 'https://github.com/havesource/cordova-plugin-push.git#86b52a7769fe80e975752f2d2db5b1abeb194802', // for IOS with SDK > 8.1.1
  // '@havesource/cordova-plugin-push': '3.0.1', // for Android with SDK <=21.+
  'cordova-plugin-device': '2.1.0'
})

That version which is not commented is supposed to fix the issue that you have above (outdated Firebase version)

[msavin]

@paulishca

You can call unregister anywhere on the client.

That’s cool but I still find it bothersome that the push tokens are not tied to the login session.

• data can leak for users that are signed out but not opted out from notifications
• quite a few can build up, and that can incurs a lot of unnecessary computation cost
• overall less control for the developer / admin

In my case, Ninjalerts is a push notifications app at the core - so we want to provide a lot of controls over them, like “Snooze notifications on my [Chrome Browser on Mac / iPhone / etc ] for 1 week”, etc… and a user can receive hundreds per day so we need to be mindful of performance, etc.

---

Meteor also uses bcrypt for the loginTokens so its just very hard to match the tokens to the login session. You also never want to publish all the loginTokens to the client. Maybe a matching public loginSessionId field can be implemented alongside the login token, plus support for some meta data, and that can open up a lot of opportunities for improved session management.

Most popular services offer pretty advanced login session management now, and it would be great if Meteor had good support for building features like these.

---

Ok the unpublished package is based on this plugin: @havesource/cordova-plugin-push.

That makes sense - I have tried adding @havesource/cordova-plugin-push@3.0.1 but continue to get that error on Meteor 2.13

[vikr00001]

Would it make sense to consider the potential push notification feature in the context of potential PWA features? I’m using a paid service, progressier.com, which does a great job of turning my Meteor web app into a PWA, and includes push notification features.

[superfail]

What about ESM support? See Feature: Support package.json exports fields · meteor/meteor · Discussion #11727 · GitHub.

[harry97]

I support most of the items on this list except for these two:

• Bring Redis-oplog to the core;

I’m afraid that after putting in work to move redis-oplog to the core, change streams would become better making this move not only obsolete but wasted effort which Meteor in a dire need of. So this must be thoroughly investigated upfront.

Honestly, it’s not that pressing. Meteor doesn’t need to double down on either strategy, at least for now. Sometimes, not doing anything is the way to go. We just need to wait things out and time will reveal the best route just like the fibers/es6 situation. For the mean time, ensure devs working on redis-oplog like @storyteller are in a good financial position to allocate time for it while keeping an eye on change streams.

Finally, if you guys think there’s a package that must be brought to the core, it’s gotta be meteor-desktop.

• Better file upload package;

I outright don’t get this point at all, may some of you guys share you pain points when dealing file uploads in Meteor? I’ve never had any issues building file upload features into my applications whether building a custom/vanilla solution that directly upload files to AWS or using something like ostrio:files or reaction-file-collections. @dr.dimitru even proposed creating a lighter alternative here.

---

There’re many great points voiced by the community but for the sake of brevity I’ll use @storyteller reply to comment on few stuff.

Storybooks

Storybooks came out of Meteor. Right now to integrate them with Meteor is painful. At the very least we should have an extension for Storybooks to provide stubs or something to make it run. I think there is a good potential here for an extension that would allow you to set different values that could be switched around in the interface like different users and so on.

I also second Jan Storybooks recommendation. The spirit of Meteor 3.0 is to align Meteor again with the rest of Node.js ecosystem and stop blocking the developers from trying out what the rest of Node.js community has to offer which makes this an absolute must. Mind you, Storybook not working with Meteor was one of the reasons forcing Vulcan to switch off of Meteor. If Meteor is determined to keep current developers and attracting new ones Meteor has gotta to play nicely with the rest of Node.js ecosystem whilst keeping its own Mantra/core philosophy intact.

Vulcan + Storybook Discussion

Importing Meteor packages (VulcanJS integration)

Browser policy packages

The browser policy packages haven’t had an update in a while to a point that other solutions started to get recommended. Personally I would like to take a look on them and give them a refresh and see if there is anything specific that Meteor can specifically offer over having a competing NPM package. If we can’t offer anything extra then we should deprecate them.

I’m all for deprecating them as suggested in Deprecate browser policy packages · Issue #11424 · meteor/meteor · GitHub

Desktop, offline and PWA
I would really like to see Electron or similar integration with Meteor. Together with that also improved options on PWA and offline capabilities and caching. Maybe something along the lines of SyncedStore

PWA is nice and all and a one size fit all solution but meteor-desktop must come first. A quick search in the forums yields many results of users complaining about meteor-desktop failing behind.

Current state of Electron / meteor-desktop

Could you explain this a little further? I don’t really understand how HCP works fully and I’ve run into this issue right now after updating to Meteor 2.0 since it’s considered an incompatible version. Tbh I don’t fully understand the role of HCP within an Electron application since we use electron-builder and electron-updater to get auto-updating working for our app. If I set "desktopHCPIgnoreCompatibilityVersion": true, will the app still get updates to both application code and npm dependen…

Always care for your day-ones, “true-believers” in Eric Hoffer words, and then branch out and try to please others. This loops back to my philosophy about caring for your “fanatics” and core nucleus of “true believers” which I lamented on before

Minimongo improvements

Minimongo was one of the things that was truly unique about Meteor like Meteor-accounts but the times are changing. I’ve been looking into this lately and I’m thinking we can use mWater/minimongo as a starting point then including inspirations from mingo, sift.js, nedb.

Minimongo must be made an independent library while adding features like aggregations, indexing and support for geo operators.

You can learn more about Minimongo shortcomings here.

Capacitor

Replacing Cordova with Capacitor fits the whole narrative of Meteor 3.0 and updating the underlying tools used in Meteor just like we did with Express/Connect. But again, it’s not urgent and we need to weigh the pros/cons vs current implementation.

[msavin]

@harry97

I’m afraid that after putting in work to move redis-oplog to the core, change streams would become better making this move not only obsolete but wasted effort which Meteor in a dire need of. So this must be thoroughly investigated upfront.

Hmmm… not sure. Changestreams is probably good for mild-real-time, but you’ll probably run into some limitations with it pretty fast… and real-time features will get much harder to implement.

Oplog tailing has always plagued Meteor as “not scalable” and Redis-Oplog has literally saved businesses that use Meteor… bringing a core solution is long overdue.

@harry97

PWA is nice and all and a one size fit all solution but meteor-desktop must come first. A quick search in the forums yields many results of users complaining about meteor-desktop failing behind.

Yes this is major pain - and Cordova is now behind too - iOS is spewing many errors and you cannot submit Android builds to the Play Store any more. I usually stuck with Meteor to avoid problems like this - but this has me re-thinking my position.

I’m not sure Capacitor is that good … it’s really just a distribution of Cordova but has many opinions and they try to sell you expensive enterprise packages for features similar to HCP.

[msavin]

@msavin

Most popular services offer pretty advanced login session management now, and it would be great if Meteor had good support for building features like these.

I just tried to create a small library that “enriches” the login token with a public sessionId, signInDate, userAgent, and potentially a lastSeen date but could not make it work with the current APIs.

Here’s what I observed:

• Accounts.onLogin actually runs on every session resume (it validates the login token) - this isn’t quite intuitive as you would think it only runs on the login event.
  • instead, it should probably be split into Accounts.onLogin and Accounts.onResume
• the newly created loginToken isn’t available when this function is called, I am guessing it is only created after the function runs, which blocks the implementation of this feature
• doing this kind of functionality as a third-party library adds a few unnecessary reads/writes, so its just much better managed in the core of the framework

---

Some other observations:

• Accounts.onLogout does not specify which loginToken was logged out, but this can be useful for a lot of things
• Accounts.onLogout might be a bit unreliable for some things, maybe better to have something like Accounts.onLoginTokenDestroyed

---

Otherwise, I think session management could be a really easy feature to implement through the core packages, provides lots of good benefits, can be backwards compatible, etc

[rjdavid]

@msavin

Hmmm… not sure. Changestreams is probably good for mild-real-time, but you’ll probably run into some limitations with it pretty fast… and real-time features will get much harder to implement.

Oplog tailing has always plagued Meteor as “not scalable” and Redis-Oplog has literally saved businesses that use Meteor… bringing a core solution is long overdue.

Definitely, agree. There seems to be a confusion on what redis-oplog brings to the table. Yes, it can replace and replicate the features of meteors oplog-tailing or change stream. But the real strength of redis-oplog is the granularity it can provide in tracking changes which brings a huge performance gain. It can track a single key on a single document if needed (at the most extreme as an example) without tracking the entire collection for changes.

Unless change stream can do such with the corresponding performance gains without tracking all changes in the entire collection, then redis-oplog deserves a core implementation.

Change stream might reach that point. But if ever it would, it’s not there, yet.

[red-meadow]

There are 2 critical issues for our team:

I. Native support for Vite or equivalent technology.

Reasoning:

1. Performance. Developing apps with rich UI has become nearly impossible because native HMR/refresh is way too slow. We had to wait 5-10 seconds for the changes to be visible in the browser. We use 2 workarounds:
   – Develop front-end separately using pure Vite. It provides great DX, everything is lightning fast, but that’s not how we want to use Meteor. We still have to make time consuming merge of the front-end and back-end.
   – Use a fork of Akryum’s vite:bundler. We have to use a fork because the package itself has unresolved critical issues related to Meteor packages. DX is ok but it’s still worse than with pure Vite: HMR is slower, page refresh is often required due to HMR errors, usage of Meteor packages is limited.
   None of the solutions are good.
2. Ecosystem. Vite allows us to use any front-end framework without additional effort.
3. Tree-shaking.

With that in mind, we consider Vite’s native support to be Meteor’s most important missing feature. We are ready to contribute.

II. Overall build/rebuild/refresh performance.
As projects grow, we still experience a lot of performance issues on Windows, even after all the possible optimizations. Using Vite partially solves the problem but without Vite it’s a nightmare. Rebuilds are too long, memory usage is high, running Meteor slows down VS Code a lot. The initial build also takes a lot of time for a big project. We would also like to have faster production builds. Again, with Vite it’s not that bad, but modern JS frameworks are far ahead in this regard.

[sabativi]

@red-meadow

I. Native support for Vite or equivalent technology.

I do agree with that, having vite will enable meteor to just works with standard front end tools.

[sebastianjs]

Any change that Angular (Typescript based) will be officially supported by Meteor?

This was possible even before Meteor switched to typescript using a 3rd party compiler from Urigo, but its unmaintained for 2 years now.

[hschmaiske]

Hey everyone,

I just wanted to say thank you for sharing your thoughts and ideas with us on the Future of Meteor.JS. Your input is incredibly valuable to us as we work on defining our Roadmap. We’ll make sure to carefully consider all of your suggestions. Thanks again for participating!

[mvogt22]

Something that I have not seen mentioned is adding MongoDB aggregation to Meteor’s Mongo.Collection class.

Using rawCollection is sufficient, but I think we could get better APM insights?

[janmp]

The reason we have the wrapper around Mongodb is Minimongo. An implementation of aggregation pipelines in Minimongo does not make sense. With aggregation pipelines we can take the data from a collection and completely transform its structure. When we sync that transformed Data with Minimongo we can’t run that transformed Data through the same pipeline again (unlike with the usual Mongo queries).

[trusktr]

Doesn’t look like anyone mentioned this, so I’ll add on!

I think that Meteor’s modules and ecmascript system is fairly out of date now, and quite a source of complexity that keeps Meteor in legacy, especially as time moves on. It was built during a time when a revolutionary set of language features were introduced but before engines supported the new features. It was necessary in that time.

Today, the language churn has slowed down compared to the ES2015 transformation of JavaScript. The majority of the revolutionary and transformational language features used today are supported in all engines, especially the features that modules+ecmascript were originally designed to support, ES Modules being one particularly huge feature.

I believe the best way forward for Meteor would be to entirely scrap the current module system, and start anew with a system designed specifically for today’s ES Module reality.

---

The current system takes ES Modules, and compiles them into a Meteor’s custom CommonJS-like module format, going against the grains we have today.

This was necessary back in early 2016, when no engines supported ES Modules. But if we were starting anew today, we’d rather build on top of ES Modules natively, allow people to write native ES Modules, and optionally allow a bundling step with tools like Rollup or ESBuild, and optionally allow enabling down-leveling (transpiling) newer language features to lower targets, both options exclusive of each other instead of coupled together like currently (where currently we handle language transpilation on top of the module system).

Right now the system (by default) compiles modern syntax into an ancient format. This is not very necessary today because most language features today are small increments compared to ES2015, and most code today can be comfortably written without transformation for all modern browsers. And IE is done for (), so we’re free from some shackles we previously had.

This isn’t to say we don’t need transpilation, but in many cases it is not needed. Having a simple and clean setup that would allow people to choose their targets in a way in which they can avoid as much transpilation as possible, without the complexity of the current module system, would be great. This new system would be opt-in, instead of opt-out like current system. Modules and bundling would be a totally separate option from language transpilation, both optional and serving only for optimization and support of older browsers.

To make this happen, we may want to take advantage (as an opt-in) of newer tools like Vite, or Astro on top of Vite, in order to provide an ES-Module-oriented system in which we also get hot module reloading and bundling (Vite uses hot-reloading ES Modules in dev mode, and Rollup for production bundling).

In fact! Maybe the baseline should just be vanilla ES Modules out of the box (with isobuild still around for back compat (i wish it weren’t)), and any tools built on top of that would need to handle vanilla ES Module code intelligently. This is the future that is currently being explored by tools, and it would be nice to be on this path starting with vanilla ES Modules.

Whatever steps we take, all the optimizations should be opt-in. The reason for this is because if we can write in vanilla ES Modules and our apps work, and then do we choose to apply optimizations, we can rest assured that our code will work for a long time without having to upgrade build systems, etc, in the future. When things work with the new vanilla standards, they will be supported for a very very long time (JS engines are not likely to remove ES Modules any time soon, browser engines not likely to remove established ways of loading assets, etc). Vanilla ESM web apps will keep running forever with very little dependency maintenance, if at all.

By starting from a fresh ES Module foundation, we’ll eliminate a bunch of complexity that I assume no one here actually wants to maintain, and we’ll then be set up for longevity and compatibility with the wider JS and web ecosystems.

---

The only problem is the work needed to take a step back. There may need to be sacrifices made in backwards compatibility in order to be aligned with the future of JavaScript. Various packages, including vite:bundler , edemaine:solid, svelte:compiler, barbatus:typescript, etc, rely on the modules package, but modules needs to be gone for Meteor be following a JavaScript-standards-aligned future path, so this change will not be a simple upgrade.

However, without this change, Meteor is going to be stuck in legacy.

[trusktr]

I think one way we can help move forward is fork Meteor, strip out all the legacy, and:

• build from the start on vanilla ES Modules
• possibly replace Blaze as the default with a simple and standards-forward Custom Element solution (I’ve made an alternative to Lit which serves as an example for making such a thing, not very much code)
• or perhaps use (or make something like) Astro that has great SSR out of the box (including client-side routing) for most popular frameworks (and custom elements!)
• what to do with the package system? The only thing it is currently really useful for is build plugins, but if we go vanilla ESM, we don’t need to start with a build.
• If we want to support JSX (React, Solid, etc) we need a build.
• Maybe we keep Meteor’s package system for back compat to load packages that expose globals (and may rely on a build), but by default a new app will start with no build stuff
• We probably need builds, but the default should be simple, without one.
• if anything, a build system should understand a vanilla ES Module website to and be able to bundle it, for production, similar in concept to Parcel (but Parcel is old and has its issues, needs rethinking from scratch and focused on vanilla ESM from the start)
• Maybe we write an HTTP/3 (QUIC) ES Module server that can push modules to the client (HTTP/2 removed HTTP push, but HTTP/3 brought it back in a better way)
  • No one has done it yet that I know of (Node.js doesn’t even have HTTP/3 yet). What if an HTTP/3 ESM server ends up negating the need for bundling?
• Maybe we make a separate NPM registry specifically for Meteor packages, as a way to not only use the industry standard NPM, but to also have a separate showcase of Meteor specific packages?
• while we’re at it, make the TypeScript support more ideal (currently some hoops to jump through to get all things well typed for both packages and meteor code itself)

Etc. There are lots of things to consider.

Maybe an incompatible fork is the only way to fully experiment to see what would be the ideal new setup, where we strip out the stuff we know we don’t want (f.e. the current ecmascript ESM emulation that was so great in the day, but is now hindering us) and go from there.

Such a fork may even help visualize what actually needs to be done in Meteor core if it isn’t mergeable back in. Or maybe it becomes its own thing. Either way it would help bring the JS community forward.

Anyone interested to experiment with this? With the right set of people (namely people that can dedicate time to making it happen), we can settle on what exactly to do, then do it. I might be able to find a few hours average per week or two.

[storyteller]

Sounds like we can make a fork like this for Deno. I think that could be more worthwhile. Right now I don’t have the time nor interest to go this deep. But after we get few versions into Meteor 3 I would be interested in getting in on looking on the next major versions.

I like the idea of our own NPM registry to keep the Meteor packages separate. Best if we could figure out some migration for existing packages, I think that would require migration of Meteor capabilities to NPM packages, so that you can do:

import { Accounts } from '@meteorjs/accounts-common'

or something like that.

[jam]

@trusktr

However, without this change, Meteor is going to be stuck in legacy.

This is an excellent point that I didn’t really appreciate until recently.

@storyteller

make a fork like this for Deno

I think Bun would also be an interesting experiment at some point.

What is the current state of Meteor?

I think the front-end clients should not be the focus on the core team. Probably just sdk + backend and hosting platform (galaxy) and third party integrations with different clients (vite, Cordova, electron, capacitors) could be maintained by the community. I personally decoupled backend from frontend, created a meteor client SDK and used it for backend/hosting. This is how Firebase, and Supabase works except that Meteor backend is more flexible.

A Meteor SDK is also intriguing. Then I suppose you could bring any framework - Astro, SvelteKit, etc. But I’m not sure if there would be a big tradeoff in “it just works so I can focus on business logic” which I think is one of Meteor’s best selling points.

[maka]

• Testing with modern testing tools (Jest, Playwright, React Testing libraries, etc.)
• Move off of Atmosphere (or open source it)