Closed ameshkov closed 3 months ago
If #466 is implemented you can simply store the extra data in the first rule's comment.
@tophf right, that will be a workaround if this change is not supported. But you know, not a beautiful one.
We discussed this at the WECG Meet-Up.
We're agreed that this is a good proposal for the structure of the rules file and would be more flexible (great idea, @ameshkov !) However, we're probably not going to do this now, for the following reasons:
declarative_net_request
field of the manifest.json file, so we already have a way of doing this.Because we wouldn't be able to just change the format and because there's no concrete use case we'd hope to solve with this change, we're unlikely to change this schema in the near future. For that reason, I'm going to close this out rather than leave it open without intention of working on it soon. However, this may be something we revisit in the future if we find a need for such data.
Thanks again for the proposal, @ameshkov , and for the discussion at the WECG Meet-Up.
Problem
The overall problem explanation is the same as in #466, we'd like to have a place in the static ruleset file where we could store additional metadata. There's rule-level metadata mentioned in #466, but there can be "ruleset-level" metadata and currently due to the structure of a ruleset file there's no good place to store it.
Can we consider changing the structure from having an array on the root level
[ rule1, rule2 ]
to something like that:In this case we can declare that the
metadata
field can be used to store additional metadata, whichever the developer needs:To not break existing extensions I propose accepting both formats (array at the root and object at the root), but having the second format recommended in the documentation.