Access a Meteor shell in the browser by typing Ctrl+'. It supports color, completions, scrollback, and everything else you’d expect from running meteor shell.
Try it out with meteor add qualia:web-shell and then type Ctrl+' in the browser.
Here’s the repo: GitHub - qualialabs/web-shell: Meteor shell in the browser
Wow that’s awesome! So to clarify, this spawns a shell on the server and then opens it in your browser? Are there any benefits on top of just being able to stay in one window (which is awesome!)
Yep! It spawns a server side meteor shell and then connects to xterm.js in the browser over websockets.
Right now the main benefit is staying in one window, which is pretty cool for some quick debugging or seeing how server side commands impact the front-end.
Some future extensions might include:
This awesome thanks for sharing, I’ll give it a try.
For us who didn’t use meteor shell much in the past, I’m wondering how are you using the meteor shell tool?
The normal way to run meteor shell is to go into your app directory and type ‘meteor shell’
Yeah I got that, but I’m wondering about the use cases for the meteor shell itself.
Yeah, what’s it for?
It’s a REPL where you can try out short bits of code on the server, run Meteor methods, and examine/modify the data in your collections using Mongo find and update.
Isomorphism for the win. Database everywhere? How about shell everwhere? 
Similar to what Sid mentioned, it’s basically the Chrome dev console but running in the context of the Meteor server rather than the browser.
In the Meteor shell, you don’t have to worry about whether or not you have permission to update a collection, or whether or not you are subscribed to the data you want to inspect (since you have direct access to the db). You can run functions that only exist on the server. You can run server side CPU profiles and look at interesting stuff like Meteor.server.sessions. You can change global variables (or even overwrite functions like Reval does) to change the behavior of your code without restarting the server.
And, with a little bit of magic, you can run Meteor shell in production and then life is awesome 
So you can do lots of stuff!
I think it should declare an explicit dependency on ReactiveVar. I don’t have the package in my project and it breaks the app because it’s trying to use ReactiveVar
Good catch; should be fixed now
well I’m just wondering: you’re saying one could use this secretly in production. As soon as people know about this though, is this read-only all the way? Otherwise I’d be pretty scared about security.
Right now there isn’t a way of running it in prod; it’s marked as a dev only package so it won’t even be included in the code produced by a production build.
However, with sufficient security precautions, I think it’d be really cool to be able to use it in prod. Here are some different ways you could restrict access:
I think some combination of the above would be sufficient.
One of the things I use meteor shell for is actually to quickly test out functions etc, because it supports ES6, and even import statements, which neither node nor babel-repl support, I believe. Quick example of testing a function, trivial, but actually not so easy to do anywhere else (you can’t play with functions in console without attaching them to the window object or something, which I sometimes do. Or you could write tests against the function and have them re-run while developing. Or have some “console.log” of running the function. I use all of these, but this is very convenient:
I would love this in production. For a long time, I was able to just run a local instance and hook up to the production mongo in order to run console commands. As soon as you start getting into crons and scheduled tasks, though, adding a local instance into the mix becomes troublesome, so I’ve been missing the console.
Nice one. This looks very promising. It’s something I had expected Galaxy to introduce a long time ago. Maybe now they can help you get it production ready and integrate your tool into Galaxy ? Restricting it to certain Meteor accounts & whitelisted IPs would make most sense in that use case.
