Add release date for support statements with multiple versions

[cincodenada]

Noticed while I was poking around testing #2966 that entries with additional flagged versions didn't have a release date tooltip. After some digging, I tracked that down to the code that adds in the release date in the first place, which did not account for support statements with multiple entries (for example, a version with flags or a prefix and then a version with full support), so these entries did not have a release date entry in the support data, and thus no tooltip in the compatibility table.

This PR extends the release date population so that it annotates the release date for all versions in an array_support_statement. Happy to get feedback on code structure, the lambda approach to this kind of thing is certainly of a style and I'm not sure if it's in line with the rest of the project. A functionally equivalent approach would be as follows, I went with the lambda because this one seemed less obviously safe in regards to object references/copying, but I tested it and it does indeed work just as well:

      for (const [browser, info] of Object.entries(block.support)) {
        const infoEntries = Array.isArray(info) ? info : [info]
        for (const infoEntry of infoEntries) {
          const added = infoEntry.version_added;
          if (browserReleaseData.has(browser)) {
            if (browserReleaseData.get(browser).has(added)) {
              infoEntry.release_date = browserReleaseData
                .get(browser)
                .get(added).release_date;
            }
          }
        }
      }

[peterbe]

I love the feature but not in love with the implementation.
First of all, I think it's bad to generate a new function for every iteration in a loop.
You could solve that by simply moving the closure function (you call it a "lambda" function) up outside the for (const [key, compat] of Object.entries(data)) { loop.

However, I think a much neater and more correct pattern would be to meet the data where it's flawed instead. I'm a bit surprised about the fact that block.support yields arrays sometimes and objects sometimes. Perhaps I've noticed this before. Perhaps it wasn't meant to be like that but the powerful nature of change caused this to happen as the project matured. What I would prefer is this:

for (const [browser, info] of Object.entries(block.support)) {
  // THAT wonderful code comment you already wrote here
  if (!Array.isArray(info)) {
    info = [info];
  }
  // WIth the oddity taken care of, from here on we know we can always loop over the `info`
  // entries.
  for (const infoEntry of info) {
            addReleaseDate(browser, infoEntry);
          }

Would you mind look into that refactoring?

[peterbe]

By the way. I really like the functionality change.

[peterbe]

CC @ddbeck soon we'll have much better tooltips about the release dates on entries where there's more than just one version "event". This @cincodenada is on fire!

[ddbeck]

This is exciting!

meet the data where it's flawed

Yeah, this is a quirk of BCD's schema. A browser in a support object can be either an array of support statements (e.g., "firefox": [ {"version_added": "…" }, { "version_added": "…", "version_removed": "…" } ]) or a single support statement alone (e.g., "firefox": { "version_added": "…" }). We've never actually done anything about it because it's not a quick fix and nobody's filed an issue about it. I'll let you do with that information as you will.

[cincodenada]

Okay great, I've reworked things to meet the data where it's at and get it into a single consistent form, and looks to work just as well indeed.

[peterbe]

🍾 🚀 Well done! And thank you!
Do you think you could help me by testing #2992?

[peterbe]

@cincodenada I think there's a bug in GitHub right now. I can't merge it. Your commits need to be signed and that option to override and ignore that (because I'm admin) isn't appearing.
To merge this, do you think you can rebase it with a signed commit?

[Ryuno-Ki]

I think there's a bug in GitHub right now.

Earlier, GitHub reported a degradation of their GitHub Actions services.

[cincodenada]

I should probably get commit signing set up anyway, so I'll do that, hopefully tonight, and rebase when I do 👍

[cincodenada]

Okay, apologies for the absurd delay here, but I finally managed to focus long enough to sit down and get a key generated and figure out how to sign my commits. I've force-pushed the signed commits to my branch, and rebased on main and squashed it down to two commits while I was at it.

Let me know if things look good on your end, and thanks again!

[peterbe]

Wohoo!!! Thanks @cincodenada !