Rename field with wildcard support

[anasshakil]

Description

This allows to rename fields using rename context item.

Example

app.post(
  "/user",
  // Promise
  body("search").rename(async (value) => {
    // do some asynchronous task
    if (value.includes("@")) {
      return "email";
    } else if (value.includes("#")) {
      return "tag";
    }
    return null;
  }),
  // Basic
  check("search")
    .rename((value) => {
      if (value.includes("+")) {
        return "phone";
      }
      return undefined;
    })
    .withMessage("An error occurred"),
  // wildcard field with short-circuiting `string`
  body("user.*.addresses.home").rename("accounts.*.users.*.addresses.billing.street"),
  (req, res) => {
    // Handle the request
    const data = matchedData(req);
    res.json(data);
  }
);

Request Body

{
    "search": "[email protected]",
    "user": [
        {
            "addresses": {
                "home":  "billing address street"
            }
        }
    ]
}

Output

{
  "email": "[email protected]",
   "accounts": [
        {
            "users": [
                {
                    "addresses": {
                        "billing": {
                            "street": "billing address street"
                        }
                    }
                }
            ]
        }
    ]
}

closes #785

To-do list

• Wildcard support

• I have added tests for what I changed.

• This pull request is ready to merge.

[coveralls]

Coverage: 99.263% (-0.7%) from 100.0% when pulling 5d4dafc on anasshakil:master into eba0cfe on express-validator:master.

[gustavohenke]

May I ask why you thought of making use of the custom validators?

Changing the meaning of the return of a custom validator will be quite disruptive for everybody, and is certainly a breaking change.

Perhaps a new function in the chain would be a better idea?

[anasshakil]

We ran into a problem where we needed to rename the search field on the bases of the input. I thought of the custom validator as a solution because it solves both of the requirements. To avoid the breaking change, we can accept the return type of an object containing a field, for example { express_rename: 'foo' }.

[gustavohenke]

Nice thinking here. I suppose that the callback should be able to handle the name to give to a field though -- as it has access to the full original path.

[anasshakil]

I had some success on renaming wildcard paths but need to do more work for wildcard support

[gustavohenke]

General question: should the old property be removed when renaming the item?

renameFieldInstance will work for setting the new property with the same value as the old field instance, but it won't touch the old one.

express-validator/src/chain/context-runner-impl.ts

Lines 50 to 54 in eba0cfe

	// Avoids e.g. undefined values being set on the request if it didn't have the key initially.
	const reqValue = path !== '' ? _.get(req[location], path) : req[location];
	if (!options.dryRun && reqValue !== instance.value) {
	path !== '' ? _.set(req[location], path, newValue) : _.set(req, location, newValue);
	}

[gustavohenke]

Nice, this is better!
A few comments here though:

1. This shouldn't stay in the Validators interface. ContextHandler sounds more like it.
2. Let's add a type specific for the rename callback, so that CustomValidator can evolve independently from the rename functionality.
3. WDYT of accepting a string value too, which works as a shortcut? For example, rename('banana') automatically renames that field to banana.

[gustavohenke]

When you move rename out of Validators, I think that this won't be necessary anymore

[gustavohenke]

Ditto for negated