parse spec info for generated libraries

[devoncarew]

• no longer write generated libraries that wouldn't contain any code
• make the process to clean up previously generated files more lightweight (instead of deleting all the source at the start of generation, we only remove files after generation that hadn't been modified)
• vend in the node web-specs package; parse that as part of generation in order to read spec info related to the generated libraries (we don't use this info as yet, but could use it to prune which specs we choose to generate for - see Consider excluding IDLs from Web Incubator CG #105)

This PR is sort of a grab-bag; thoughts welcome.

---

• I’ve reviewed the contributor guide and applied the relevant portions to this PR.

Contribution guidelines:

• See our contributor guide for general expectations for PRs.
• Larger or significant changes should be discussed in an issue before creating a PR.
• Contributions to our repos should follow the Dart style guide and use dart format.
• Most changes should add an entry to the changelog and may need to rev the pubspec package version.
• Changes to packages require corresponding tests.

Note that many Dart repos have a weekly cadence for reviewing PRs - please allow for some latency before initial review feedback.

[devoncarew]

Here's the info we parse for each spec entry:

  {
    "url": "https://fetch.spec.whatwg.org/",
    "seriesComposition": "full",
    "shortname": "fetch",
    "series": {
      "shortname": "fetch",
      "currentSpecification": "fetch",
      "title": "Fetch Standard",
      "shortTitle": "Fetch",
      "nightlyUrl": "https://fetch.spec.whatwg.org/"
    },
    "organization": "WHATWG",
    "groups": [
      {
        "name": "Fetch Workstream",
        "url": "https://fetch.spec.whatwg.org/"
      }
    ],
    "nightly": {
      "url": "https://fetch.spec.whatwg.org/",
      "status": "Living Standard",
      "alternateUrls": [],
      "repository": "https://github.com/whatwg/fetch",
      "sourcePath": "fetch.bs",
      "filename": "index.html"
    },
    "title": "Fetch Standard",
    "source": "specref",
    "shortTitle": "Fetch",
    "categories": [
      "browser"
    ],
    "standing": "good",
    "tests": {
      "repository": "https://github.com/web-platform-tests/wpt",
      "testPaths": [
        "cors",
        "fetch"
      ],
      "excludePaths": [
        "fetch/fetch-later",
        "fetch/metadata",
        "fetch/private-network-access"
      ]
    }
  },

[kevmoo]

LOVE IT! should wait for 👍 from @srujzs , though

[srujzs]

Nice, thanks! While ideally we should probably move the addition of the web spec to a PR that uses it, I'm totally okay with keeping the processing of the web spec here.

[devoncarew]

Nice, thanks! While ideally we should probably move the addition of the web spec to a PR that uses it,

Yeah, totally - this would normally be the 1st half of a PR. After looking at the info we were parsing however, it didn't immediately jump out at me which libraries not to include in the generation. I think this will need someone w/ more domain expertise to incrementally prune the generated libraries.

We may even want to use the info to generate some libraries into a src/experimental directory. It could be nice to make some APIs available, but w/o strong guarantees wrt api stability.

[srujzs]

We may even want to use the info to generate some libraries into a src/experimental directory. It could be nice to make some APIs available, but w/o strong guarantees wrt api stability.

This would be great! One of the concerns I had was that due to the noise of some of the in-progress API definitions, we'd be releasing breaking changes too often. Moving them to a folder where we make no guarantees of stability should hopefully minimize those breaking changes.

[kevmoo]

Turns out that info is NOT as useful as I'd hoped. It's too complex to explain here...