[Testing] Removing the && node.parent.type === "JSONProperty" logic doesn't fail any tests. So one of the following is true:

• The logic is necessary (node.parent doesn't always have .type === "JSONProperty"), and test cases should be added to exercise this logic
• The logic is unnecessary (node.parent always has .type === "JSONProperty"), so should be refactored to be unnecessary, removed, or replaced with a type assertion

This brings up a couple of interesting test cases actually:

// package.json
{
  "some-custom-array": [ [] ],
  "some-custom-object": [ {} ],
}

What should the rule do in those cases?

My gut instinct is that it should report on them by default, because that's just a weird thing to do - even in custom fields. Similar to #741 (comment): if someone has a tool-specific use case for an empty field, then they can always file a feature request for the rule to add an allowlist or something like that.

cc @michaelfaith

I think they are two cases.

1. It includes key and value, e.g. "xxx": [], "yyy": {}. The array or object have one key
2. It includes value only, e.g. "xxx": [ {}, [] ]. The array or object have no key

So I should update my code like this code:

JSONArrayExpression(node: JsonAST.JSONArrayExpression) {
    if (!node.elements.length) {
	report(
	   context,
	  node.parent.type === "JSONProperty" ? node.parent : node,
	);
     }
},

You can check the video

Hmm, that's a good question. I do wonder if there might be a legitimate use case for this. Such as resetting some tool config? I.e. some tool has a default config that's applied in a root level package.json, and a nested package.json wants to clear the config at the lower level? Not sure how likely that is, but, to your point, we could always take care of it, and see if anyone brings an actual use-case forward.

Hmm, that's a good question. I do wonder if there might be a legitimate use case for this. Such as resetting some tool config? I.e. some tool has a default config that's applied in a root level package.json, and a nested package.json wants to clear the config at the lower level? Not sure how likely that is, but, to your point, we could always take care of it, and see if anyone brings an actual use-case forward.

Maybe we can consider a variable that defined in schema to choose what to keep and what to remove for user?

In this first iteration, I'd advocate for keeping it simple. And if we can't articulate a substantive real-world use-case, then I think @JoshuaKGoldberg 's suggestion of covering it for now, until someone brings a valid usecase forward makes sense. It's easier / less intrusive to relax a rule than it is to make a rule more strict. So, if you already have the empty nested case working, let's go with that.

In this first iteration, I'd advocate for keeping it simple. And if we can't articulate a substantive real-world use-case, then I think @JoshuaKGoldberg 's suggestion of covering it for now, until someone brings a valid usecase forward makes sense. It's easier / less intrusive to relax a rule than it is to make a rule more strict. So, if you already have the empty nested case working, let's go with that.

I agree with you. Can you review this latest code? I have the empty nested case working. Please tell me if something need to improve.

[Docs] Could you please write up descriptions and examples for this file, similar to other rule docs files?

(noting Michael's comment, that works too if you prefer)

I think I can have a try.

@chouchouji if you end up having any difficulty, I'm happy to help with it.

@chouchouji if you end up having any difficulty, I'm happy to help with it.

Thanks, I will write docs after completing this rule logic.