Wow!!! I have been wrestling with an app for 2 months. I want to serve desktop and mobile. But I’m using onsen UI in my current project. I don’t really know how to get the web version to not be a magnified version of the android app.
Do I have to create another project and use the first as the backend? Any pointers as to how to go about creating such a setup would be appreciated.
Update: we have done that in the meantime. Delayed our launch even more but it was worth the couple months of blood, sweat and tears
My understanding is that Node 12 is coming to Meteor 1.9. It’s amazing to me that nobody has mentioned this.
What’s the main benefit for Meteor users you’d see in this new version? Better performance?
I’m honestly not qualified to say. What I’m aware of is native support for async iterators, and I’ve heard the crypto module has been improved (which some npm packages require). In general, updating from Node 8 to Node 12 will indicate Meteor maintenance is keeping Meteor modern.
Perhaps another forum member can add to this? How does this help Meteor users? Based on the GitHub history, this was a community priority, so I had guessed that there was canonical knowledge on what has changed to the state of the art.
So looking through articles/changelogs here are the improvements that I can see, since Node 8:
So to sum up, performance & analytics improvements and updated modules.
Thanks for the write-up, highly appreciated. If I understand things correctly, the modules support is still experimental, but they plan to release a final version end of this year. Will be interesting to see how this matches to the Meteor modules approach.
It is becoming inconvenient being stuck on node8, where other parts of our infrastructure requires later node version e.g. Angular 8 requires node10. When is 1.9 likely to surface?
Did you try to customize your Meteor app build against node 10?
Guessing when the next Meteor version is going to be released is extremely difficult. I think it will be some time after 1.8.2 is released. Judging by the current development progress I guess that 1.8.2 will come in late autumn and 1.9 towards the end of the year within Q1 of 2020.
BUT remember that is a very rough estimate of mine and it all depends on when @benjamn decides to move things to the next stage. The development has weeks where there are a few alpha/beta/rc releases and then nothing for a long time.
in around 50 days time Node v8 (v8.15.1 as bundled with Meteor 1.8.1) goes out of LTS, having been in maintenance LTS since Jan 01 2019. So, without an update to Meteor’s node to v10+ before this deadline, none of us can run our meteor apps in a supported fashion. Our security team have already taken a shot across our bows, saying we’ve got to stop running node v8.
@andylorenz You can try out the current 1.9 beta, which uses node 12:
meteor update --release 1.9-beta.2
At the very least, having more data about potential bugs will help finish it.
I’m personally surprised it hasn’t gotten to release candidate already with so few days of Node 8 support left 
We are on the last RC version for 1.8.2. I hope we release it soon (next week?)
After that, I hope we can move 1.9 also to RC as it is just trailing the updates from 1.8.2 recently. But I honestly have not tested it more thoroughly than with 1.8.2 which we are running now in production
I’ve been running 1.9 since alpha6 version, it’s node 12, tons of improvements, it also runs on node 13 with no issue. My devtools fork uses node 13 and I’ve been using 1.9 on production for a few months now.
It’s not complicated to migrate your apps (I easily migrated my ERP, 6M lines of code, +200 meteor packages)
A few days ago 1.8.1 was merged into 1.9 (also yesterday). I’ve been following the changes on that repo everyday as this runs flawlessly on BSDs.
Wow!
How long are rebuilds in development? What % of overall code is in packages?
We’ve had build perf issues on much less code, so curious how you’ve dealt with it
Builds take between 7 to 9 minutes on average. 100% of the code is in packages (I have no code outside packages, I made a package for every feature I wanted to add to the ERP). Rebuilds are fast, depending on the change, between 10 to 40 seconds. I guess Meteor is smart enough to just rebuild the package I modified.
I have several npm dependencies that are native node modules, dev builds take more time when I need to recompile these. Bundle size is ~130MB.
Build / development machine is:
CPU: Core i7 4710HQ
HDD: 7200rpm
OS: FreeBSD 12.1
FS: ZFS
NODE: 13.0.1
I have a much smaller project, which takes over 30 minutes to compile - at least on Windows. :-/
10-40s is still pretty painful, but still really good for a project that size!
Sounds like I should take more advantage of packages 
Yeah, that sounds like a good idea even for my projects. Shouldn’t be too difficult, given my project structure, after a bit of code cleanup.
Hah, I was getting a meteor app running using azure app services, and azure devops CI, and when using a windows server for the build, it would time out after 55 minutes.
When I switched to a linux server for the build, it finished in 4 