Hi, I am looking for advice on getting our team’s meteor project upgraded to the latest working version. Our project started at 1.4.4.1 and I have since upgraded to 1.8.3 . This has been quite a learning process as I have worked on this project for years but have not spent time with upgrades/dependencies.
Our project contained coffeescript which added a lot of headache with the upgrades. I put our project through a “decaffeinate” and I’m unsure the extent of what broke. The biggest hurdle has been going from an all inclusive infrastructure to now being very modular on 1.8. Getting the correct packages installed, imported, and working has been difficult but I’ve managed to get this far.
I’m at a point now where the project builds and runs but is incredibly broken. The HTML templates are breaking and it seems most underlying functionality is inaccessible or broken.
My upgrade path plan is as follows:
1.4.4.1 → 1.5.4.2
1.5.4.2 → 1.6.1.4
1.6.1.4 → 1.8.3 (I made it here)
1.8.3 → 2.3
2.3 → 2.7
2.7 → 3.0
3.0 → 3.2
I am not a meteor expert and know just enough to be dangerous. Would appreciate feedback or general advice regarding this upgrade.
Would you be doing something differently?
Would you recommend a different upgrade path?
Was running decaffeinate on the project a terrible idea?
Will the upgrades in the future be more or less difficult than what I have done so far? (Incredibly difficult to answer given this little context but I am telling myself that transitioning the project to work with modular packages will be the hardest part.)
I am the only member of my team working on this currently so any comments are appreciated. Thanks!
It’s definitely doable to migrate your application to 3.3, it’s no biggie. I’ve done it before and seen many others do it. So, don’t fear the process yet treat it with respect.
Now, before making assumptions here’s what you did:
“decaffeinate” entire project → magic stuff → you don’t know what went through → kaputt?
Running blank operations during migrations is a hit or miss, and grokking through a change you don’t understand is even worse. It’s ok to try these hit-or-miss tactics but seize it if it doesn’t work immediately. Stacking unknown solutions atop would only make matters worse.
Second, you’re tackling two beasts at once:
Upgrading Meteor versions
Coffeescript to JS
It’s best to tackle each one on its own. So my prescription for you is to start off with Coffeescript to JS and instead of running one big command, go through files one by one and use LLMs to help you, so you’re just reviewing things and make sure everything is ok. The best thing about this is that you don’t have to migrate you app to JS in one swoop. You can do couple of files at a time and validate your progress.
Baby steps and one at a time, that’s how it goes. Best of luck!
I’ve read it works well but can’t verify yet. Coffeescript dependencies prevented me from upgrading or building and running it through that project solved my issues for upgrading. Was hoping the project would relatively unaffected.
It would likely be best to revert back to the original version and do the coffeescript conversion like you suggested. I had considered doing this but was hoping I would be able to plow forward and knock out 2 birds with 1 stone. As unlikely as it is, I was hoping that someone who has used decaffeinate might see this and be able to comment on it.
Is reverting to the prior Meteor version and switching branches all it would take to switch back? I have been hesitant to move backwards on meteor versions for testing and have only been moving forward.
Excluding project specific issues, what is expected to be the largest hurdle for getting meteor from 1.4 to 3.3? Is my comment correct that the switch to a modular infrastructure for 1.8 will be the biggest pain?
Install Kilo Code extension in VS Code. Connect Kilo to a large free LLM with Open Router.
Let it do the job, feature by feature.
Write a markdown document with what you want to achieve, let it look at an old Meteor git branch and at a new one so it knows how to do the job.
In this post you have a reference to the Meteor documentation built for LLMs: Meteor Docs updates – we are removing the AI chat - #8 by grubba
Have a file in your root folder .kilocodeignore and add all the sensitive files and folders.
I do not do contractor work, but I do friendships. If you need, I can offer you 2-3 hours to have you set up with the tools and some rules and prompt to do the job.