Feature Request: Running multiple instances of the same Meteor app in development?

Problem
I'm building a couple of 3rd party packages that relies on mutiple instances of the same application running against the same database. I'm currently unable to run multiple instances of the same source, unless I copy the entire source and run my second instance from it. I think there's a number of scenarios where it would be valuable to easily run the same app on different ports.

From my perspective, this would be pretty cool:

D:\> cd documents\projects\someMeteorProject
D:\documents\projects\someMeteorProject> meteor --port 3000
D:\documents\projects\someMeteorProject> meteor --port 4000

If I try this right now, my second instance gets the following output:

[[[[[ ~\D:\documents\projects\someMeteorProject ]]]]]

=> Started proxy.

<runJavaScript-77>:168
      throw error;
            ^
Error: EBUSY, rmdir 'D:\documents\projects\someMeteorProject\.meteor\local\build\programs\server'
PS D:\documents\projects\someMeteorProject>

I imagine this is because it's trying to rebuild on top of the code that has already been built and is executing?...

[clayne11]

Could you provide a use case where this would be beneficial?

I think I've made my use case pretty clear - I'm doing a cross instance package which is explicitly easier to develop running two instances of the same codebase whilst developing. Is that clearer, or should I be more specific?

[rozzzly]

No @Goatic. Can you be more specific? Can you make that more clear?

I'm doing 3 meteor packages - one of them, which the other two relies on, is polling the database to let other server-instances know it's online. When an instance goes down, other instances will clean up the data the dead instance left behind. My other two packages sprinkle some user presence on top of this functionality, allowing server-instances to set users as online, and marks them with a unique instance ID, so that other instances can take them offline in case that instance goes down.

Developing this package, I'm trying out different ways of doing this efficiently, and it's really hard to develop when I can't have multiple copies of the same codebase running at the same time.

Scaling out applications horizontally, if you're developing packages that allow this, it's beneficial to be able to run multiple copies in development as well. Having to make copies of the codebase, bump version number with every minor change to have them reflected across apps with the local package installed, is tiring - and it would be really nice to just have multiple copies of the same thing running at the same time! 👍

This is really easy to do in Node, and I hope that's the case (or will be) with Meteor as well!

Is that descriptive enough, or is there anything I could add to this to make my use case clearer?

[stubailo]

I think the easiest way to achieve this would be to have Meteor use some other directory as the .meteor/local directory. So you could say something like:

METEOR_LOCAL_DIR=/tmp/app-number-two meteor -p 4000

Note, this doesn't work right now - I'm just presenting an idea for how it could work if it were implemented.

Thanks @stubailo! This was exactly the kind of solution I was looking for 👍 I'll just add it as a package.json script, and it will be easy to automate the setup!

Should I keep the issue open for the sake of a potential pull request?

[stubailo]

@Goatic yeah the thing I wrote isn't an actual thing you can do today, it would be a new feature to be added. I'm hoping someone can do this via a pull request.

Basically you would need to modify this line:

meteor/tools/project-context.js

Line 91 in 88d43a0

self.projectLocalDir = options.projectLocalDir ||

And have it read from process.env.METEOR_LOCAL_DIR if that variable exists. Then you should be able to run many copies of Meteor from the same app.

no problem... If I actually manage to submit the request correctly, lol. Thanks for the guidance 👍

[laosb]

@stubailo Meteor should have read it from process.env.METEOR_LOCAL_DIR, I think? Else the workaround you provided shouldn't work?

So what we need to do is detect if we already have one instance running, and generate another local path?

[stubailo]

Else the workaround you provided shouldn't work?

Yes the workaround I provided doesn't work. It's an idea for how someone could file a PR to fulfill this feature request.