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

Generally improved validation and added l10n validation #196

Closed
wants to merge 5 commits into from
Closed

Generally improved validation and added l10n validation #196

wants to merge 5 commits into from

Conversation

pkuczynski
Copy link
Contributor

@pkuczynski pkuczynski commented Apr 6, 2018

  • add validation for l10n/css.json
  • verify unused keys in l10n/css.json - found a couple of unused keys and deleted them - was I right about it?
  • move all definitions into common definitions.js
  • generally improve the schema validation in few places

It would be possible to implement similar technique done for l10n also to definitions#enums, so there would be no need to manually define those enums, but instead validate if values exist in l10n and vice versa. What do you think about this idea?

@frenic
Copy link
Contributor

frenic commented Apr 6, 2018

Maybe sort order should be linted as well?

@pkuczynski
Copy link
Contributor Author

ajv does not offer such validation, as JSON does not require props order. I can add it manually using javascript. Can you create a ticker for this?

@pkuczynski
Copy link
Contributor Author

@frenic can you merge this PR?

@frenic
Copy link
Contributor

frenic commented Apr 6, 2018

I wish! 😆 I don't have the privilege to do that.

@wbamberg
Copy link
Contributor

wbamberg commented Apr 6, 2018

I do, but this is a big (though impressive!) change, and I probably won't have time to review it today.

@frenic, you can definitely help me by reviewing it, if you have the time.

BTW @pkuczynski , @lahmatiy , I want to make a new release of this repo as soon as possible, are there any open PRs you would really like to have merged before I do so? (or conversely, any potentially risky ones that you would not like merged?)

Copy link
Contributor

@frenic frenic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

JavaScript is looking good and works fine. A small comment but it's really not a big deal.

I don't have the confidence enough to review the data changes though.

console.log(' Style – OK')
} else {
noErrors = false
console.log(' Style – Error on line ' + jsonDiff(actual, expected))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be nice maybe if this displayed all the diffs rather than just one line at the time.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's ok, jsonDiff returns all the diffs.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I understood the problem you pointed out. Yep, the logic were changed, but in another place (see my comment above).

@frenic
Copy link
Contributor

frenic commented Apr 6, 2018

#189 would be nice to have

@pkuczynski
Copy link
Contributor Author

This PR doesn’t really change data, except l10n where I removed unused strings. All the rest are improvements on the validation

@pkuczynski
Copy link
Contributor Author

There is a good question if we should not remove the whole enums in the definition.json and implement it differently using the same technique as for serching for unused translations? That would be my choice...

@frenic
Copy link
Contributor

frenic commented Apr 7, 2018

This PR doesn’t really change data, except l10n where I removed unused strings.

I meant that I haven't worked with JSON data to this extent before. So my knowledge about schemas is a bit limited.

@frenic
Copy link
Contributor

frenic commented Apr 7, 2018

There is a good question if we should not remove the whole enums in the definition.json and implement it differently using the same technique as for serching for unused translations? That would be my choice...

That sounds like a major change? @wbamberg In that case maybe it should be in another PR so it can be discussed separately?

@pkuczynski
Copy link
Contributor Author

pkuczynski commented Apr 9, 2018

@wbamberg

@wbamberg
Copy link
Contributor

wbamberg commented Apr 9, 2018

Please note that #189 needs a fix in l10n/css.json before I can merge it. I think the other issue there (removing grid-row-gap and grid-column-gap) doesn't have to block merging though.

@pkuczynski
Copy link
Contributor Author

@wbamberg #189 fixed

@wbamberg wbamberg mentioned this pull request Apr 10, 2018
@pkuczynski
Copy link
Contributor Author

@wbamberg conflicts solved. Ready to merge!

Copy link
Contributor

@lahmatiy lahmatiy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great work!
I left a few notes.

"$ref": "properties#/names"
}
},
"enums": {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why we need to split types for paths enums/names/* and enums/text/*? I believe it can be a plain list of types, i.e. groups instead of enums/names/groups and initial instead of enums/text/initial

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The reason why I split them, was because I am cross-checking enums/text with l10n/css. So if the key is missing in l10n or l10n has keys which does not exists in this list, the build will fail. This way I found some unused l10n strings. I felt like it is a good idea to keep things tidy.

I was also considering on dumping the whole enum/text and simply pull the values in js directly from individual props in *.json. This would limit the overhead of adding the new values into definitions.js. What do you think?

var ajv = new Ajv({ $data: true, allErrors: true });
var dictPaths = ['api', 'css', 'l10n'];
var hasErrors = false;
var fs = require('fs')
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not fair, you have changed a code style 😢

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Apologies. That was my editor default settings. Do you want me to bring back the semicolons?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not just a semicolons. Previously maintainers ask me to change a code style you found before your changes.
Also there is a big delta with a small effective changes that hard to find. I suggest to left changes in the script only about the main goal and move further refactoring to a separate PR.

console.log(' Style – OK')
} else {
noErrors = false
console.log(' Style – Error on line ' + jsonDiff(actual, expected))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's ok, jsonDiff returns all the diffs.

@@ -54,7 +54,7 @@
"prefix": {
"syntax": "<symbol>",
"media": "all",
"initial": "\"\"",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe it should be "\"\"" since it's a valid CSS value

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I changed this so it will place nicely with l10n check. Can bring it back if you want?

@@ -81,7 +81,7 @@
"suffix": {
"syntax": "<symbol>",
"media": "all",
"initial": "\". \"",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe it should be "\". \"" since it's a valid CSS value

@@ -188,7 +188,7 @@
"groups": [
"Microsoft Extensions"
],
"initial": "\"\"",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe it should be "\"\"" since it's a valid CSS value

var ajv = new Ajv({ $data: true, allErrors: true });
var dictPaths = ['api', 'css', 'l10n'];
var hasErrors = false;
var fs = require('fs')
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not just a semicolons. Previously maintainers ask me to change a code style you found before your changes.
Also there is a big delta with a small effective changes that hard to find. I suggest to left changes in the script only about the main goal and move further refactoring to a separate PR.


console.log();
noErrors = noErrors && checkStyle(absFilename) && checkSchema(absFilename)
Copy link
Contributor

@lahmatiy lahmatiy May 6, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change omits checking after the first fail. We want to see all the problems at once, not just first one.

console.log(' Style – OK')
} else {
noErrors = false
console.log(' Style – Error on line ' + jsonDiff(actual, expected))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I understood the problem you pointed out. Yep, the logic were changed, but in another place (see my comment above).

@wbamberg
Copy link
Contributor

@pkuczynski , I'm sorry to have not reviewed this PR. It seems from your description that the PR does a few different things, would it be possible to split it up into separate PRs that each do one thing? That would greatly help me find the time to digest and review it.

@schalkneethling schalkneethling deleted the branch mdn:master November 24, 2021 09:49
@pkuczynski
Copy link
Contributor Author

Shame it never got merged after 4y

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

Successfully merging this pull request may close these issues.

None yet

5 participants