Perfect! I would love to be a part of that discussion!
My thought is that Meteor pub/sub could be utilized using Apollo Live query since Meteor pub/sub with Mongo is already reactive. I think from what I saw in the GraphQL Summit 2017 videos that Apollo uploaded to YouTube the main difference between live queries and subscriptions was whether the backend was reactive or not. To me, since Meteor’s server side Mongo is reactive, it would be nice to be able to utilize that from any front end using Apollo Client. Just @live whenever reactivity is needed and let the Meteor magic work on the server and push updates to any client running Apollo Client.
What’s the current status on having change streams (implemented in MongoDB 3.6) in Meteor?
When is Meteor going to move to MongoDB 3.6? Any MDG statement on this?
@km29 Using change streams with Meteor is being tracked in:
Change streams have limitations that make them difficult to use with Meteor for certain tasks (see the issue thread for more details). It’s early days for the change stream spec though, and Mongo devs are watching that issue thread.
That being said, updating the Meteor Tool to use Mongo 3.6 (without integrating change streams) can happen sooner than later. I’ve marked https://github.com/meteor/meteor-feature-requests/issues/233 as pull-requests-encouraged in-case anyone is interested in helping out.
It should be possible to implement service workers already - and even better in 1.6.2, because you can add additional build targets (I think - I’m not sure how to do that, but it’s on my short list to figure it out).
Do you mean source maps in production? These are already available during development.
One place source maps fall apart is in async/await code - that should be better in 1.6.2 because of legacy bundle splitting (what is that feature going to be called?).
I see… I would like to have my sentry errors mapped to source maps. As of now I get errors, but I’m not sure exactly where in the human readable code they are. In expo, they have a hook that shoots up a source map to sentry every time you deploy… would be nice to be able to do something like that with a npm script flag and maybe your settings.json
The import directory was added so that meteor doesn’t eagerly load files within that folder. This was a quick solution, a better approach is to allow developers the option of specifying the entry points for lazy loaded directories so they’re not forced into a specific app structure or empty client/server folders. So the changes coming to 1.6.2 is a backward compatible way to provide this option.
I believe they will answer some problem in a separate issue. there is a discussion to be able to move the bundled Javascript and CSS files like in a normal HTML file.
But apparently you can still use the old way of mixing eager loading and imports statement
Non-js assets will still be eagerly loaded following the same rules (So will probably need to live in an imports folder if you want to explicitly import them)
Also note that the loading behavior of non-JavaScript resources is not
affected by packageJson.meteor.mainModule. Only resources added by
compiler plugins via addJavaScript are subject to the new configuration
option. If a compiler plugin calls addStylesheet or addHtml, those
resources will still be included unconditionally in the HTML document
rendered by the web server. While you could try to import these resources
from JavaScript, you would only be importing any JavaScript resources the
compiler plugin registered using addJavaScript, and not the actual HTML
or CSS resources.
That’s weird - I wasn’t able to get my html file to even load in my attempt. I ended up reverting my change to use mainModule because I couldn’t figure out how to get it to load the main html file (using static-html).
Er, actually it is working now. I wonder if it was because I at one point moved the entry file (main.js) out of the client directory where the HTML files are.
Following transpiling of node_modules (1.6.2), more transpilation config options, for instance to properly resolve and alias packages for dependencies.
As an example, if you make react-native available to your app through meteorInstall aliasing it to react-native-web, dependencies that rely on react-native (as a peer dependency at least, like react-navigation, react-native-simple-markdown, etc), won’t find it).
