Create an automated way to render diffs of the spec introduced by proposals

[tschneidereit]

Currently, spec proposal authors have to manually create rendered versions of the parts of the spec their proposal changes, including diff highlights. It'd be great if we could do something more automatic, perhaps even with more utility.

A while ago, @arai-a created a diff viewer for versions of the spec, capable of rendering rich diffs between different revisions of the spec. It might be possible to update that in a way that allows for rendering diffs between the current HEAD of the spec and forks representing proposals. Ideally, this'd be integrated into the draft spec such that the draft contains links to proposals. Much easier would be for proposals to be forks of the base spec version and by default use the diff viewer to render the changes they apply to the spec.

To try out the diff viewer, clone the repository, check out the gh-pages branch, and open index.hml.

[arai-a]

Updated ecma262-compare to support the current structure, and now the live demo is showing some recent revisions and some PRs
http://arai-a.github.io/ecma262-compare/

[arai-a]

Updated ecma262-compare to support the current structure, and now the live demo is showing some recent revisions and some PRs
http://arai-a.github.io/ecma262-compare/

[jmdyck]

What determines the list of PRs in the top drop-down? I was interested in seeing what it did with #1125.

[jmdyck]

What determines the list of PRs in the top drop-down? I was interested in seeing what it did with #1125.

[arai-a]

I just downloaded some of currently opening PRs.
I can update if necessary

[arai-a]

I just downloaded some of currently opening PRs.
I can update if necessary

[arai-a]

added 1125.
will be reflected shortly.

[arai-a]

added 1125.
will be reflected shortly.

[jmdyck]

Thanks!

[jmdyck]

Thanks!

[ljharb]

@arai-a is this something that could be set up to automatically work with all repos under the tc39 org, as well as all the PRs under each of those repos?

[ljharb]

@arai-a is this something that could be set up to automatically work with all repos under the tc39 org, as well as all the PRs under each of those repos?

[arai-a]

I don't know much about automation or CI on GitHub.
the way to setup and run script manually is described here.
https://github.com/arai-a/ecma262-compare/blob/gh-pages/README.md

I'll check how GitHub's CI works.

[arai-a]

I don't know much about automation or CI on GitHub.
the way to setup and run script manually is described here.
https://github.com/arai-a/ecma262-compare/blob/gh-pages/README.md

I'll check how GitHub's CI works.

[ljharb]

ah, I was hoping there was a way to do it in clientside JS.

[ljharb]

ah, I was hoping there was a way to do it in clientside JS.

[arai-a]

to my understanding, it at least needs to build HTML file from source, for each revision to compare,
so, if that part can be either skipped or done in client side, this could be implemented as client side JS.

[arai-a]

to my understanding, it at least needs to build HTML file from source, for each revision to compare,
so, if that part can be either skipped or done in client side, this could be implemented as client side JS.

[arai-a]

Okay, locally the client-side-only JS application is almost-working,
except that spec.html needs build. in order to convert Markdown-like-thing to HTML.
(so, currently the diff has no structure)

I'll check what's actually done while building.

[arai-a]

Okay, locally the client-side-only JS application is almost-working,
except that spec.html needs build. in order to convert Markdown-like-thing to HTML.
(so, currently the diff has no structure)

I'll check what's actually done while building.

[arai-a]

(one more issue is that GitHub API has rate limitation, and I have no idea how I can bypass it without disclosing access key)

[arai-a]

(one more issue is that GitHub API has rate limitation, and I have no idea how I can bypass it without disclosing access key)