Closed johnschult closed 9 years ago
After implementing this I realized that as the settings are not project specific, setting meteorAppPath
for running meteor-helper
in one project would not work in another project that has the Meteor application in the root directory.
This seems to be a common request and possibly on the 1.0 roadmap.
Still, that's interesting and helpful. For tackling multiple instances, I rely on mup.json
. There could be something to do for enhancing this to handle sub directories.
I'm in plain middle of a massive Saltstack configuration for easing Meteor deployment on bare metal, Docker and so forth. Once done, I think I should be able to integrate some best practices in Atom. Will see.
+1
I've merged it as well as the #33. Thanks.
It should work with multiple instances of Atom since I don't use the reactive nature of the settings. Thus, we are able to setup multiple instances of Atom on different apps :wink:
It's available in the 0.24.0.
Sweet 👍🏻
++john
On Apr 14, 2015, at 3:03 PM, Pierre-Eric Marchandet notifications@github.com wrote:
I've merged it as well as the #33. Thanks.
It should work with multiple instances of Atom since I don't use the reactive nature of the settings. Thus, we are able to setup multiple instances of Atom on different apps
It's available in the 0.24.0.
— Reply to this email directly or view it on GitHub.
Summary
When using something like Iron Meteor or when a developer has their Meteor app in a subdirectory under the project path, it was not possible to run Meteor. I added a configuration setting to allow starting Meteor in a directory other than the current working directory.
The Atom configuration supports using ordering and titles so I ordered the configuration and added titles to fix things like Mongo Oplog U R L.
Change Description
meteorAppPath
configuration setting (fb3e3ec).