search

tc39 / proposals

Tracking ECMAScript Proposals
https://tc39.github.io/process-document/
18.27k stars 717 forks source link

Tooling implementation status #140

Open vjpr opened 6 years ago

vjpr commented 6 years ago

Links to "Tooling implementation status" issues for some proposals, so people can see whether their tools support the proposals. I check them when they are supported in WebStorm, Babel and Flow.

By tool

ljharb commented 6 years ago

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

mathiasbynens commented 6 years ago

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.

vjpr commented 6 years ago

@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.

xtuc commented 6 years ago

Copying my comment here: https://github.com/tc39/proposal-pipeline-operator/issues/123#issuecomment-387025644.

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.

oyilmaztekin commented 5 years ago

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

littledan commented 5 years ago

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:

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

oyilmaztekin commented 5 years ago

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.

littledan commented 5 years ago

What about experimenting here with compat data formats based on MDN browser compat data, with the goal of eventually upstreaming it there? See also https://github.com/mdn/browser-compat-data/issues/3280

oyilmaztekin commented 5 years ago

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"
      }
  }
}
ljharb commented 5 years ago

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.

oyilmaztekin commented 5 years ago

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

screen shot 2019-03-04 at 19 07 09

ljharb commented 5 years ago

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

oyilmaztekin commented 5 years ago

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.

littledan commented 5 years ago

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.

ljharb commented 5 years ago

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

ExE-Boss commented 4 years ago

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.

leobalter commented 4 years ago

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.