Please enable a 'vi' editing mode for the mongo shell.

• Similar to vi mode in bash
• Similar to https://www.npmjs.com/package/mongovi

A first cut of key bindings would be:

Basic command mode/editing mode toggling:
i Insert before cursor
Esc Toggle to command mode

Cursor motion keys:
h Move left
j Move down
k Move up
l Move right

w Move to next word
b Move to the beginning of the word

0 Move to the beginning of the line
$ Move to the end of the line

And delete/change:
x delete next character to the right
d

{motion} delete amount specified by {motion}
c

{motion} delete amount specified by {motion}
and also put you in insert mode

The CLI commands, like mongosh, can be used in bash scripts to quickly implement reliable data processing pipelines. Thanks to the aggregation pipeline your clients can do pretty complex things with this, despite a small number of lines and zero infrastructure. Unfortunately, in the recent versions, the output of those commands is no longer JSON. When mongosh returns results, it is now in pseudo-JSON, which can no longer be parsed directly by other standard tools like jq. This makes interpreting the results needlessly complicated. In addition, error messages are not output in JSON either (simple unformatted strings in that case), which adds another useless layer of complexity to handle the various errors.

My suggestion is that all the CLI tools, especially mongosh, should always output (or have at least an option to do so) its results, messages, and errors in a standard JSON format that can be readily consumed by other standard tools. Hopefully, you guys can find a way to expand the resulting JSON structures while retaining their backward compatibility as much as possible, instead of redefining the same fields' types over and over. This would make using those commands reliably inside scripts a breeze.

Note: I understand that the results might contain stuff like ObjectId() which are not JSON, but in that case, it is possible to rewrite them as { ..., ObjectId : "asdasd", ... } or { ..., ObjectIds : ["asda", "err34e", ...], ...}.

Problem Statement/Rationale

Let's say you have a directory full of scripts.

For now, I need to do a load('script path') for each script.

Wouldn't it be great if I could do load('*') within the directory, and load them all one after the other with this one liner ?

Expected Results

load(/*/) -> all the files in the directory, sorted by alphanumerical (maybe we could also configure a locale in mongo configuration file or something like that to change collation)

Actual Results

load(Regex Pattern) doesn't work, because it searches a path.

Additional Notes

if it's too complicated to make load compatible with regex patterns, we could imagine that an other function could do the job, like findRegex() or something, where it accepts a string and this string has to be a regex pattern

MongoSh is a developer tool, obviously. So as a developer, git is always a part of it. Supporting git command inside mongosh will help us save a lot of time.

Here's some of my implementation:

const git = (command) => {
try {
return execSync(`git ${command}`).toString();
} catch (e) {};
return null;
};
const listBranches = () => {
const branches = git(`branch -a`).split(/\r\n|\n|\r/).filter(notEmpty);
return branches.map(branchObj);
};
const pull = (remote = 'origin') => {
return git(`pull ${remote} --rebase`);
};
const log = (cnt) => {
const _cnt = Number(cnt) || 32;
return git(`log --graph --all --oneline --decorate=short --max-count=${_cnt}`);
}


For loading external script into MongoSh current session, currently we have the load() function, which is enough for the task. But I found myself using my own functions instead. So I would like to describe those as suggestion to improve MongoSh:

loadScript()

This function is basically has the same function with load(). But has 1 major difference: all relative paths in the script has the same base directory with the script itself, not the current MongoSh working directory.
For example:
- Script "D:\MyProject\src\script.js" have these references: "test.js", "../test2.js"
- Current working dir process.cwd(): "C:\MongoSh"
- Path resolved using load("D:\MyProject\src\script.js"): "C:\MongoSh\test.js", "C:\test2.js"
- Path resolved using loadScript("D:\MyProject\src\script.js"): "D:\MyProject\src\test.js", "D:\MyProject\test2.js"

My implementation:

const loadScript = function (name) {
  const currentDir = path.resolve();
  const absPath = path.resolve(name);
  try {
    process.chdir(path.dirname(absPath));
    load(path.basename(absPath));
  } catch (e) {
    print(e);
  }
  process.chdir(currentDir);
}

loadFolder()

This function load all scripts in folder and its nested folders (including symbolic links) using loadScript() behavior.

Why I use this in the first place? Because of .mongoshrc.js. I have a lot of self implement functions, so I put them all in mongoshrc folder in the same location with .mongoshrc.js. And then load them all inside .mongoshrc.js. But since load() function do not interpreted relative path based on script location, so I have to change my working directory like this:

{
  const currentDir = path.resolve();
  process.chdir(`${process.env.HOME ?? process.env.USERPROFILE}/mongoshrc`);
  load(`myScripts.js`);
  process.chdir(currentDir);
}

It is better if .mongosh.js loaded with loadScript(), then the script is just:

loadScript(`mongoshrc/myScripts.js`);

or

loadFolder(`mongoshrc`);

Hope I make myself clear. Thanks for reading.

There is an initiative in the tech community to replace non-inclusive terms with more inclusive ones and I'd like to get the community's take on it. I think the biggest offenders are terminology referring to "slaves" and "masters", but I'm sure there are others that might fall into that category. Although I'm sure nobody meant any harm by using these terms, I think we can and should do better.

I'm currently working my way through the m103 replication course and I see in replication configuring there's a term "slaveDelay". Also a "rs.isMaster()" method. I'm suggesting replacing "slave" with "worker" and "master" with "main". I know these changes have a gigantic impact logistically speaking, but I think it's time to prioritize the human impact.

An initiative like this ties into a larger movement across the tech industry to create a better, more professional workplace for everyone. See this article for a similar initiative taken on by GitHub: https://www.zdnet.com/article/github-to-replace-master-with-main-starting-next-month/#:~:text=By%20default%2C%20GitHub%20uses%20the,of%20a%20source%20code%20repository.&text=1%2C%202020%2C%20any%20new%20repositories,will%20be%20left%20as%20is.

currently, when creating a role, we need to list one collection per db for custom role

db.getSisterDB('admin').createRole({role : 'readWriteCollectionXY',
privileges : [ {resource : {db : "databaseA", collection : "***"}, actions : ["find", "insert", "update"]},
{resource : {db : "databaseA", collection : "yyy"}, actions : ["find", "insert", "update"]} ],
roles : []
})

having an option to list all the collections in one db with the same permission would be a nice thing to have.

db.getSisterDB('admin').createRole({role : 'readWriteCollectionXY',
privileges : [ {resource : {db : "database_A", collections : ["***", "yyy"] }, actions : ["find", "insert", "update"]} ],
roles : []
})