Are you a fan of Node.js REPL? Do you extensively use the REPL to try out small code snippets quickly while you are working? If so, Baapan is for you…
Personally, I’m a HUGE fan of NodeJS REPL and I use it every day and I can’t live without it. There are plenty of alternatives and IDE extensions to be used instead of REPL, but nothing can beat the good ‘ol REPL.
Back in the days, I had a huge headache when using Node REPL. I mostly use REPL to try out various array operations (map/reduce/filter etc.), and object operations (extract what I want from a huge json etc.). Sometimes I wished they had pre-installed lodash into REPL because it can be of help working with complex object arrays. Also, sometimes I wanted to try out an npm module on my data. I could do this easily by using something like RunKit. But I didn’t want to paste and work with my data (potentially sensitive) on some 3rd party website. I wanted Node.js built-in REPL to be capable of fetching and requireing any NPM module I want on-the-fly. That’s how baapan was born.
Get it from here: https://npmjs.com/package/baapan
Why Baapan
Why do you need baapan instead of using something like RunKit? While online code editors/playgrounds such as RunKit/CodeSandbox/Repl.it are useful to try out snippets quickly, it doesn’t feel safe to paste sensitive/proprietory data on those editors, does it? Since baapan runs entirely on the local Node REPL, you don’t need to worry anymore. It may not be an editor as such, but it’s Node REPL and much more !!
How does it work?
As I said earlier baapan is nothing but a Node REPL with some extended functionality. It has a monkey-patched require() which intercepts require calls, and if the required module could not be resolved, it immediately npm install the module and requires it onto the REPL right-away.
Similar to the Node REPL, you can spawn as many baapan instances as you need. Each baapan instance has its own isolated workspace. All the module installations occur into its workspace without polluting any other modules directory. When the user gracefully exits the REPL, the workspace is automatically removed which prevents accumulating stale workspaces filled with temporarily used NPM modules.
The workspace path of the current REPL instance can be retrieved by BAAPAN_WS_PATH environment variable.
> process.env.BAAPAN_WS_PATH
'/Users/djayasekara/.baapan/workspace_44023_1562678000424'</span>
Feel free to give it a try, and let me know any your feedback. If you’d like to contribute to baapan have a look at the repository. ✨
Top comments (2)
Love this idea. It makes a lot of sense to do it this way. I've faced the exact same requirements regularly. Would love to contribute.
Thank you, Nirmal. Feel free to check out the repository.