Workflow & v1.5x (.meteor in local dirs) (solved, just theorizing now)

Good Day.
I’ve been developing with Meteor for a good year+ now. First I got used to Blaze, then that fell out of favor for React (or other view layers). I wanted to start a new project, but it seems that with ver1.5 .meteor/ is installed in my home dir as ~/.meteor on my macOS.

Looking for ways other devs set up their work environments to have multiple versions of Meteor on their dev machine.

For example, I’m still maintaining a ver1.4 app, which has it’s .meteor dir within the project dir. Now everything wants to put .meteor in my local dir. I’ve even moved that new ~/.meteor dir to project dir, but then when I either meteor run or meteor npm start meteor insists on downloading a new distro to my local dir as it doesn’t find one there.

Also, it seems a config was changed (in my PATH?). When there is a valid distro ~/.meteor and I meteor npm start from within my ver1.4 dir, it loads (and even says that there’s a patch for my 1.4 version) so I’m assuming that it’s using the local project dir’s .meteor dir. When I remove ~/.meteor dir, and try to run within my 1.4 dir guess what? “this is your first time using Meteor!” and a download and install commences within my local root dir (~/.meteor).

Meteor keeps getting end-developer unfriendly (not as easy to spin up a new project as it was in pre version1) but is a much better end product, just…

Stumped in Michigan.

The project .meteor directory has existed for a long time and it holds the project specific meteor configuration. the $HOME/.meteor holds all the packages and code that are shared across projects like Meteor itself and any atmosphere packages you’ve installed.

So that’s why removing your home meteor dir resulted in saying you had no Meteor installation because you literally had removed it.

1 Like

To follow up, your $HOME/.meteor will be home to many different versions of meteor, packages, and things like meteor-tool. If you remove that folder and try to run a meteor project, you will get that error message. Installing meteor will then install the latest version. If you try to run a project that is on, say, 1.4, then running meteor in that folder (after installing meteor) will grab the version you need for that project.

I have projects from 1.1 through 1.5 on my machine, and all work as expected. When $HOME/.meteor gets too big, I clear it out and then any subsequent project runs re-download the packages I need.

Hope this helps!

1 Like

Thanks for the feedback.

So I see that my Meteor-1.4 app’s ~/projectA/.meteor/packages wants to use standard-minifier-css@1.3.2.
While my Meteor-1.5+ app wants standard-minifier-css@1.3.4 – and that both of those are found within my $HOME/.meteor/packages/standard-minifier-css/ dir.

Where/When does garbage collection come into play for $HOME/.meteor?

Just doesn’t seem to be as “clean” as keeping everything needed for a project within that project’s dir. What am I missing with this pattern? It’s not saving space on my local dev machine. While searching for an answer I came across many Qs where there were permission issues throwing errors (where the $HOME/ dirs have different permissions than the project – guessing someone did a sudo somewhere they shouldn’t have), but that issue still becomes one where putting everything in the project dir would seem to be “cleaner.”

Also, not having pushed a Meteor v1.5+ app up to a server to be live, is it much different than pre-1.5?

Thanks for thoughts and feel free to just point to a resource.

There isn’t really any cleanup that gets done in that folder, AFAIK. I’ll typically clean it out every few months, which requires downloading some of the packages again, but when you have multiple projects on multiple versions, you can see that folder grow pretty quickly.

I don’t think setting up a 1.5+ app is any more difficult than any other version, so long as you have your mup/containers/whatever other solution aligned, so that things like node are at the version they need to be to run that version of Meteor.