Log results from update-bcd-file

[teoli2003]

To feed this into the script generating the PR, we need to know what has been changed (addition and removal, but the script using it will be able to filter it). This will be used for the description.

This log format has no strong format requirement as long as it is a JSON file, and that it is not too long (it shouldn't log what has not changed).

I can imagine that not all use of this tool will need such a log file, so having a command line option (with the name of the log file as an argument) is likely a good idea.

cc/ @mzgoddard

[ChrisC]

@teoli2003 Would a slimmed-down version of the UpdateState object that the update script is using to update BCD work for this? Here's an example of what that might look like:

[
  {
    browser: "safari",
    path: "api.AbortController",
    statements: [
      {
        version_added: "≤13.1",
      },
    ],
  },
  {
    browser: "chrome",
    path: "api.AbortController",
    statements: [
      {
        version_added: "85",
      },
    ],
  },
  {
    browser: "chrome",
    path: "api.DeprecatedInterface",
    statements: [
      {
        version_added: "≤83",
        version_removed: "85",
      },
    ],
  },
  ...
]

This format would probably be the easiest output to generate based on the current version of the update script. Let me know what you think!

[ChrisC]

@teoli2003 I'm also curious if you have any thoughts on the best place to write this json log? Should it be created in the user's local copy of the bcd-collector repo, or in the local copy of the browser-compat-data repo (since this also where the update script is ultimately making the bcd file changes)?

[teoli2003]

At first sight, it would work well. One question, though:

What will happen if we have { version_added: "180" } and a new run for 180 doesn't detect it anymore (for example, a feature removed during the beta phase) ?

(I will try to test this tomorrow).

I'm also curious if you have any thoughts on the best place to write this json log?

By default I would say where the script run. Ideally, we should be able to configure it with a parameter like -o pathtofile.

[ChrisC]

What will happen if we have { version_added: "180" } and a new run for 180 doesn't detect it anymore (for example, a feature removed during the beta phase) ?

I'm not sure I totally understand this scenario. So are you saying there may be instances where a vendor may remove a feature without an incremental version change and without some kind of flag on the feature? If that's the case, I don't think the script will currently overwrite previous version_added results if a later test on the same feature from the same version produces a false result. I am doing some parallel work in #909 that will begin to log a contradiction like this though (if I'm understanding the scenario correctly).

[teoli2003]

Yes, you are right: the scenario: where we run the script before the release (and a feature can be removed during the beta process) is outside the scope of this PR.

Let's do the regular scenario first and carefully think of this case later (if it is relevant).

Thank you!