`consistent-destructuring` improvements

It could be good to add an option for ignoring redefined properties of sources:

// I don't see a reason to use destructuring for `edge`
const { chrome, ie, safari } = module;
// ...
if (!module.edge && ie) {
  module.edge = '12';
}
// ...
if (!module.edge) {
  // ...
}

It could be good to add an option to ignore some sources or properties:

const { getPrototypeOf } = Object;
// ...
// `Object.prototype` here looks better than just `prototype`
if (getPrototypeOf(object) === Object.prototype) {
  // ...
}

[futpib]

I think examples provided here can be rewritten in a better way that does conform to the latest (31.0.0) unicorn rules:

@zloirock’s from https://github.com/sindresorhus/eslint-plugin-unicorn/issues/1005#issue-783525204:

let {chrome, ie, safari, edge} = module;

if (!edge && ie) {
	edge = '12';
}

if (!edge) {
	// ...
}

// If you *really* need to mutate `module.edge` for some reason,
// do it after you changed all destructured variables you wanted to change:
Object.assign(module, {
	chrome,
	ie,
	safari,
	edge,
});

if (Object.getPrototypeOf(object) === Object.prototype) {
	// ...
}

@brettz9’s from https://github.com/sindresorhus/eslint-plugin-unicorn/issues/1005#issuecomment-758325847

This already passes unicorn rules, but you could rewrite it to use even more destructuring with IMO even better readability:

const {request} = event;
const {cache, mode, url} = request;

doSomething(cache, mode, url);
doAnother(request);

I don’t get exactly which improvements are proposed here. I think this needs more clear examples with comments like “This line is reported (and/or autofixed) but I think it should not be reported” or “This line is not reported but I think it should be reported (and/or autofixed)” each in a separate issue. Even better, if you feel like it, write a failing test for maximum clarity.

[brettz9]

I might just add that I think there are essentially three approaches that are favored, none of which is necessarily superior, but the current rule only allows one of them.

1. Require it everywhere possible (the existing rule)
2. Require it wherever a destructuring structure has already exposed the specific variable (@fisker’s proposal)
3. Require it wherever a destructuring structure currently makes it feasible (my own preference)

By my own preference, I mean the following:

const {a, b, c: {d}} = obj

obj.c // Should *not* report since it would require retooling (a new line)
if (!obj.f) { // Should *not* report as it would require retooling (replacing
                 //    with `let` or a `let` and `const`)
  obj.f = '12';
}
obj.e // Should report since it can just be added to the destructuring