| 17:49 | <littledan> | looks like we just have 14 hours or so of topics scheduled, so we should have a couple hours of time for breakouts at the end of the meeting, if people don't all fall asleep |
| 17:53 | <ljharb> | scheduling constraints are likely to be plentiful this time around |
| 20:15 | <keith_m__> | What are people's thoughts on adding a YAML object analogous to JSON? |
| 20:21 | <bradleymeck> | keith_m__: no |
| 20:21 | <keith_m__> | bradleymeck: porque? |
| 20:22 | <bradleymeck> | YAML is a fickle thing, 1.2 is generally not terrible but it has breaking changes over time |
| 20:22 | <bradleymeck> | 1.0 has the norway bug |
| 20:22 | <bradleymeck> | if YAML was more stable / didn't have as much surprise factor, sure |
| 20:23 | <keith_m__> | gotcha, that's fair. I didn't know about the norway bug (amusing) |
| 20:24 | <keith_m__> | bradleymeck: Do you know of a common configuration format that's both stable and easier to read than JSON? Would such a format be worth considering? |
| 20:24 | <bradleymeck> | keith_m__: thats the most famous one, but there are others |
| 20:24 | <keith_m__> | right that's why I went with YAML |
| 20:25 | <rkirsling> | I guess TOML is the new hotness |
| 20:25 | <bradleymeck> | no, i mean bugs/surprises in YAML |
| 20:25 | <bradleymeck> | keith_m__: what are you seeking over pretty printed JSON i guess is the question |
| 20:25 | <bradleymeck> | more value types? |
| 20:25 | <keith_m__> | JSON is just annoying to modify |
| 20:26 | <keith_m__> | because it's structure is very restrictive |
| 20:26 | <keith_m__> | its* |
| 20:27 | <keith_m__> | Also, you can't have comments IIRC |
| 20:27 | <bradleymeck> | i don't know of one that is significantly less restrictive and relatively non-surprising, (see YAML surprises) |
| 20:27 | <bradleymeck> | keith_m__: sure you can, just use the same key as the one that follows it |
| 20:27 | <keith_m__> | lol |
| 20:27 | <bradleymeck> | JSON.parse(`{"main": "this is a comment?", "main": "why"}`) |
| 20:28 | <keith_m__> | a masterpiece of design right there! :P |
| 20:29 | <bradleymeck> | but yea, if your config has comments the fear of using comments as data is real |
| 20:30 | <rkirsling> | what was the reason for not adding comments to the JSON spec again? just that we really don't want the format to split into two separate version? |
| 20:30 | <rkirsling> | s |
| 20:33 | <bradleymeck> | rkirsling: comment used as annotation originally, now spec updates would be breaking to *everywhere* |
| 20:34 | <bradleymeck> | hence the repeated statements in plenary about how it is luckily not facing any issues still so we don't need to update it |
| 20:34 | <rkirsling> | how do you mean annotation? |
| 20:34 | <ljharb> | keith_m__: also yaml is terribad |
| 20:35 | <keith_m__> | ljharb: I'm open to other suggestions lol |
| 20:35 | <keith_m__> | I picked YAML because that's what happens to be all over WK (from before my time) |
| 20:36 | <ljharb> | rkirsling: json has many forms of comments :-p `{ "//": "this is a comment", "foo": "this is a comment about foo", "foo": "this is the real value of foo" }` |
| 20:37 | <rkirsling> | yeah I mean bradleymeck covered that but I'm trying to understand/remember the reason |
| 20:37 | <keith_m__> | rkirsling: I believe because it was people were putting parser annotations in them or something |
| 20:38 | <rkirsling> | ohhh |
| 20:38 | <bradleymeck> | rkirsling: {/*@type {Person}*/name:'Bradley Farias'} or somesuch being used to auto conversion |
| 20:38 | <keith_m__> | I don't think that's a great reason to exclude them but 🤷♂️ |
| 20:38 | <rkirsling> | yuck |
| 20:38 | <ljharb> | i assume it's also a fear of ecosystem churn - all of a sudden an unimaginable amount of json parsers would need updating |
| 20:38 | <ljharb> | but yeah as soon as there's a DSL in there, all sorts of security holes are inevitable |
| 20:38 | <keith_m__> | ljharb: I think rkirsling meant back in the day when it was first created |
| 20:38 | <rkirsling> | yeah I mean there's a definite benefit to a data format staying the same |
| 20:38 | <ljharb> | ah |
| 20:38 | <bradleymeck> | keith_m__: it just means JSON wouldn't be cross system stable, not the worst thing honestly but it would mean you have to know what *kind* of JSON you are handling |
| 20:39 | <rkirsling> | well yeah back in the day would be good to know too but maybe harder to answer |
| 20:39 | <keith_m__> | Oh, sorry I meant when they were removed |
| 20:39 | <bradleymeck> | i have enough issues thanks to "__proto__", "constructor", etc. being allowed in our language |
| 20:40 | <keith_m__> | lol |
| 20:40 | <bradleymeck> | keith_m__: the number of github issues is real |
| 20:40 | <bradleymeck> | and makes me sad |
| 20:40 | <keith_m__> | On which repo? |
| 20:40 | keith_m__ | is curious |
| 20:40 | <ljharb> | prototype pollution issues are on many many repos |
| 20:41 | <ljharb> | they're not even attack vectors 99% of the time, but the 1% means everyone gets spammed with related CVEs :-/ |
| 20:41 | <rkirsling> | just gotta ensure that the first character of the file is a fancy J, like 𝔍 |
| 20:41 | <keith_m__> | ljharb: wouldn't that be true regardless of `__proto__`/`constructor`? |
| 20:41 | <ljharb> | keith_m__: of CVEs, yes, but `__proto__` is a particularly easy one for libraries to fall into |
| 20:42 | <keith_m__> | Oh you mean using it at all? |
| 20:42 | <ljharb> | i mean having a magic string property that changes the observable characteristics of the object in a fundamental way |
| 20:42 | <keith_m__> | I don't actually know too much about XSS/library CVEs |
| 20:42 | <ljharb> | constructor is more about reachability than breaking things |
| 20:42 | <keith_m__> | gotcha gotcha |
| 20:42 | <Bakkot> | I think TOML is... ok |
| 20:43 | <Bakkot> | better than YAML at least |
| 20:43 | <ljharb> | agreed, but low bar |
| 20:43 | <Bakkot> | wish it didn't have so many moving parts |
| 20:43 | <Bakkot> | I wonder why there isn't a popular but also not terrible json replacement |
| 20:44 | <ljharb> | json5's pretty popular |
| 20:44 | <Bakkot> | is it just that no one has written one? |
| 20:44 | <ljharb> | other than "people put it in .json files", how is json5 terrible? |
| 20:44 | <Bakkot> | ah yeah I forget about json5 |
| 20:44 | <ljharb> | (i'm assuming it is and i just don't know the ways) |
| 20:46 | <ljharb> | at this point i bet if node natively supported parse/stringify for JSON5, the push for npm to support `package.json5` would be pretty strong, and then the push for browsers to add `JSON5.parse` would become stronger |
| 20:46 | <ljharb> | but there's a lot of heavy dominos in that chain |
| 20:46 | <Bakkot> | probably would need to have it in more languages first |
| 20:46 | <Bakkot> | don't think I've seen a python project touch it, e.g. |
| 20:47 | <ljharb> | right |
| 20:47 | <keith_m__> | Yeah, I think it's mostly an other languages thing |
| 20:48 | <Bakkot> | my big problem with json5 is that it has the same issue as json, in that it does not specify an interpretation of the values |
| 20:48 | <Bakkot> | so you end up with the twitter snowflake bug |
| 20:48 | <keith_m__> | That's probably true for most of the "nice" configuration formats no? |
| 20:49 | <Bakkot> | I think TOML does not have this problem? |
| 20:49 | <keith_m__> | Oh, I've never looked at TOML... |
| 20:49 | <Bakkot> | well, it says "Floats should be implemented as IEEE 754 binary64 values.", at the very least |
| 20:49 | keith_m__ | looks |
| 20:49 | <keith_m__> | Is that not expected in JSON? interesting... |
| 20:50 | <Bakkot> | the JSON spec does not impose any semantics at all |
| 20:50 | <keith_m__> | In JS that's obviously true |
| 20:50 | <Bakkot> | cf https://github.com/qntm/fastjson |
| 20:50 | <bradleymeck> | keith_m__: my old tweet on the glory of constructor/__proto__ injection vector: https://twitter.com/bradleymeck/status/1204225330103422976 |
| 20:51 | <keith_m__> | Bakkot: LGTM lol |
| 20:54 | <keith_m__> | bradleymeck: >.>, yikes |
| 23:23 | <devsnek> | if we have to add something new can it be toml |