-
-
Notifications
You must be signed in to change notification settings - Fork 5
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
More RFC 8259 nits #68
Comments
Thanks for the feedback. I'm unclear on what it is you're suggesting. Are you saying we should update some existing rules, create new rules, etc.? Can you be more specific? |
Also, can you please add a link to the RFC for easy reference? |
RFC8259 is the current IETF description of JSON. It is aligned with ECMA-404, but focuses more on interoperability between systems rather than on how Here are more explicit recommendations:
Sorry I wasn't more clear before. |
Got it, thanks. These all seem like good additions to me. Only question is the naming of |
|
Or maybe And yes, but if you could please do a separate PR for each task, it would be appreciated. |
I'm making progress on a PR. What do we think about |
Partial fix for eslint#68.
A new rule that checks that the top-level item in a JSON file is either an array or an object, as suggested by RFC8259. Not turned on in the recommended config because the software that had this issue is almost entirely obsolete. Refs eslint#68.
Note that this is affected by humanwhocodes/momoa#164 in the sense that in JSON5 mode, unquoted escaped keys are not yet unescaped in the same was as all other keys, and will not trigger this lint yet. When the momoa issue is fixed, released, and we have updated to that version, uncomment the last test in no-duplicate-keys.test.js. Suggest that we create a separate issue in this repo to track that change. Refs eslint#68
Flag subnormals, numbers that are flushed to zero, and overly-large integers. Refs eslint#68
Those three PRs should cover this issue. |
Good question. It's definitely not a problem in JavaScript, but I'm unsure of other languages. |
Let's leave it be then. 8259 doesn't say anything about it, so it's a separate issue if we decide it needs to be added. |
* test: Matching escaped and unescaped keys. Refs #68 * Update momoa, uncomment test and ensure it now passes. * fmt
Flag subnormals, numbers that are flushed to zero, and overly-large integers. Refs eslint#68
* feat: Add top-level-interop rule. A new rule that checks that the top-level item in a JSON file is either an array or an object, as suggested by RFC8259. Not turned on in the recommended config because the software that had this issue is almost entirely obsolete. Refs #68. * Code review responses * Update src/index.js Co-authored-by: Milos Djermanovic <[email protected]> * Fix quoting --------- Co-authored-by: Nicholas C. Zakas <[email protected]> Co-authored-by: Milos Djermanovic <[email protected]>
* test: Drive-by nit to fix test name When the test was copied from a previous example, the name in the comments wasn't changed. * feat: Catch more unsafe numbers Flag subnormals, numbers that are flushed to zero, and overly-large integers. Refs #68 * Rework unsafe zero. Fix code review issues. * Add a few more tests * Rework error text * Move detailed description of no-unsafe-values to readme. * fmt * Add values to errors * Make links in readme * code review issues
I think this is now fixed. Suggest closing? |
Rule details
Check as many of the constraints from RFC 8259 marked "interoperable in the sense"
What type of rule is this?
Warns about a potential problem
Example code
Participation
Additional comments
RFC 8259 marks several potential interoperability issues with "interoperable in the sense":
no-duplicate-keys
)no-unsafe-values
currently will not catch integers outside that range that have not gotten all the way to being +/-Infinity.no-unsafe-values
catches this now.no-duplicate-keys
only needs some tests added to check that "a\b" and "a\u005Cb" are duplicates.The text was updated successfully, but these errors were encountered: