Add Encoding Stardard by adding browser.webidl.json #300
Conversation
|
Still too much diffs to review? |
|
Or no interest to introduce a new file? |
|
Or what? Just too busy? |
|
Rebased, an appreciation for @DanielRosenwasser to merge from master branch 👍 |
|
@saschanaz You may as well split this PR into some small and clear units with leaving this PR open. In this case, maintainers can improve the project by small steps. And you can add a piece of your changes to the project. Besides, it will also reduce the diff size of main PR. For example, I sometime split my PR like this: #324, #326. |
|
This really includes Encoding Standard + WebIDL types. The latter is way smaller so probably a good point to split. |
|
What is the status of this PR? I want this for avoiding a monkey patch to |
|
@saschanaz can you rebase please |
| @@ -0,0 +1,381 @@ | |||
| { | |||
There was a problem hiding this comment.
This is for F# type provider to compute JSON types. Otherwise it has to read the whole file which will take more time.
There was a problem hiding this comment.
thanks. we should name it as such then.
There was a problem hiding this comment.
The current sample.xml has the same purpose, do we also want to rename it? typeprovider.xml/json?
inputfiles/browser.webidl.json
Outdated
| @@ -0,0 +1,97 @@ | |||
| { | |||
There was a problem hiding this comment.
what is the source of this file?
There was a problem hiding this comment.
is that one you hand authored? I am asking mainly for naming purposes. i think browser.webidl is not a good name for this one..
|
It’s from https://github.com/saschanaz/webidl-serializer/tree/json2?files=1
Using W3C webidl2.js to parse from web specs.
|
|
then maybe we should name the generated .json file with the same name as the input webidl file. this way you can tell where it came from easily. |
|
The input files typically have the same name index.bs, which probably is not a good name. BTW I'm merging several json files into one file browser.webidl.json, do we want to get splitted JSON files? |
I actually meant the name of the spec. so that would be the title in this case.
there is no reason to have them all in one.. it would be nice to be able to match the same structure that comes in from the webidl |
|
Splitted JSON files need more changes on TSJS-lib-generator as it currently assumes we have only one type definition for a name (it uses name-type mapping). In reality we have several partial definitions. |
|
If we are to generate several d.ts files (in other words, n d.ts files for n webidl files) then it may be simpler. |
An earlier version of this script used to do that. it did that by reading them alll, merging the input into a single json object, then processing this. we can do something similar here.
that is a possibility as well.. |
That's exactly what I'm doing on the upstream. Anyway, this PR doesn't cover any partial definitions so any merging can be a future work. I'll do the splitted JSON thing first. |
|
@saschanaz with #383 in, can you try merging the .json files in. |
|
See #405 if anyone has subscribed this 😁 |
Adds Encoding Standard-defined types by WebIDL-generated browser.webidl.json, superceding #227.
This PR allows progressive merging of standard W3C/WHATWG specs into lib.d.ts, which means more specs can be added on top of this.
Why JSON?
XML libraries including xmldom are not being well maintained because of the transition to JSON and other formats.
Currently the JSON data is converted to existing browser.webidl.xml objects to reduce code duplication, while the ultimate goal is to replace browser.webidl.xml completely.