Tooling implementation status about proposals HOT 17 OPEN

If we're going to try to store JSON data about proposals in this repo, let's start by trying to make all the markdown files be generated from such JSON - iow, so there's a single source of truth (the JSON). Once that's done, adding info about each proposal to the JSON file would be a smaller task.

from proposals.

This is a great idea, to improve tracking of implementation status. There are many different places that are all tracking this same sort of thing, and I wonder if we can somehow unify on one data source to all update. The current tracking locations are:

• proposal repositories (sometimes in issues, sometimes in the explainer)
• MDN browser compat data
• ChromeStatus and similar pages for each browser (WebKit, Firefox, Edge)

I wonder if MDN might be a convenient place to centralize on, cc @Elchi3 @mathiasbynens

from proposals.

Another thought, the readme file can be used as a "single source of truth". There is no need to be JSON or another file placed somewhere. There will always be a README file in this repository and it will be committed to the repo. It would be better if we parse this markdown as an AST to find changes on the children of the table node with traversing. Then we can create an HTML or JSON file which also can be provided via REST API based on this tree.

You can inpect the tree at here

from proposals.

The proposals I author or champion include an “implementations” section in the README that link to open bugs or list implementation status in JavaScript engines, web browsers, and tooling such as Babel. I wouldn’t mind if this became a requirement.

Note that Stage 4 already requires multiple implementations, so it’s only a small step to require listing that info in the repository somewhere.

from proposals.

Copying my comment here: tc39/proposal-pipeline-operator#123 (comment).

FYI we are wanting to centralizing the implementation status on the future TC39 website: https://github.com/tc39/tc39-web-draft. Tracking will be easier.

from proposals.

There's certainly not an issue with adding a .travis.yml and a package.json.

from proposals.

Also, the MDN browser compat data might be a good example of how data can be stored. Holding data as a JavaScript Object might provide some benefits such as it's useful for standardization and it's easy to iterate for all crawlers.

from proposals.

What about experimenting here with compat data formats based on MDN browser compat data, with the goal of eventually upstreaming it there? See also mdn/browser-compat-data#3280

from proposals.

Typically this is something each individual proposal should be tracking on its own repo.

from proposals.

@ljharb Typically this is something each individual proposal should be tracking on its own repo.

This is the idea behind this issue. It links to tracking issues in other proposal's repos. Have a look.

Having an issue like this open in proposal repos allows people to make comments when the status needs to change. Its worked well for 6 months.

Ideally this should be replicated in the readme though in a standard way as @mathiasbynens
suggests. Maybe something like docs/implementations.md with a link at the top of the proposal. And then these issues can be used for people to comment on implementation status changes.

from proposals.

I want to take action on this issue. Considering the ideas from here and from other issues that is related, perhaps we can start off creating a markdown file in this repo to organize "implementation status". Consequently, it can be used for crawlers of beta website or some informative section of this repo. Either way, it needs to be clarified how we can move forward.

Related issues:
beta/#61
beta#59
beta#60

from proposals.

Maybe we can start with a template. It would be useful for gathering ideas about which properties of the proposal we should hold in this object.

{
  "import()": {
      "proposal_url": "https://github.com/tc39/proposal-dynamic-import",
      "author": "Domenic Denicola",
      "champion": "Domenic Denicola",
      "implementation": {
        "babel": {
          "added": true,
          "tool_url": "https://www.npmjs.com/package/babel-plugin-syntax-dynamic-import"
        }
      },
      "test_status": {
        "advance": false,
        "merged":true,
        "no_pr":false,
        "waiting":false
      },
      "Last Presented": {
        "date": "November 2016",
        "prst_url": "https://github.com/tc39/tc39-notes/blob/master/es7/2016-11/dec-1.md#14ii-import-open-issues-and-stage-3-discussion"
      }
  }
}

from proposals.

@oyilmaztekin that sounds great as long as we have a tool to verify the markdown syntax in CI.

from proposals.

If we want to start these kinds of job in CI in here, it looks like package management needs to be implemented. I am not sure it is appropriate to create package management in here. This repository only contains markdown files and focuses on the documentation. Maybe triggering builds through request or plume-lib's trigger-travis job can be used. Any thoughts?

I already started to implement a parser in this repo but it would be better if we have a consensus.

from proposals.

Lots of repositories in the tc39 org have Travis-CI jobs and a package.json which download code from npm. Is this what you're getting at? I don't think it would be a problem to use a similar pattern.

from proposals.

We could probably have Travis CI extract the proposal data from README.md and the other files on the master branch and commit it as JSON to the gh‑pages branch.

from proposals.

In a personal listing I actually have a yaml (could be a json) file that I parse with Jekyll to create a MD and html outputs to create these tables. I always avoid re-editing markdown tables.

from proposals.