Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tooling implementation status #140

Open
5 of 7 tasks
vjpr opened this issue May 6, 2018 · 17 comments
Open
5 of 7 tasks

Tooling implementation status #140

vjpr opened this issue May 6, 2018 · 17 comments

Comments

@vjpr
Copy link

vjpr commented May 6, 2018

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
Copy link
Member

ljharb commented May 7, 2018

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

@mathiasbynens
Copy link
Member

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
Copy link
Author

vjpr commented May 7, 2018

@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
Copy link
Member

xtuc commented May 7, 2018

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.

@oyilmaztekin
Copy link
Contributor

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
Copy link
Member

littledan commented Jan 20, 2019

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
Copy link
Contributor

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
Copy link
Member

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

@oyilmaztekin
Copy link
Contributor

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
Copy link
Member

ljharb commented Jan 21, 2019

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
Copy link
Contributor

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
Copy link
Member

ljharb commented Mar 4, 2019

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

@oyilmaztekin
Copy link
Contributor

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
Copy link
Member

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
Copy link
Member

ljharb commented Mar 5, 2019

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

@ExE-Boss
Copy link
Contributor

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
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

9 participants