JS parser doesn't handle \u2028 and \u2029 like modern browsers

[blixt]

So historically trying to use the output of JSON.stringify("\u2028") as JavaScript would break evaluation because JS would consider that character a newline, hence the string would be unterminated. But since then modern browsers have changed to not consider it a line break, as documented here:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/JSON/stringify#issue_with_plain_json.stringify_for_use_as_javascript

You can also test this in your browser by running this round trip of encoding and evaluation:

const js = "export default " + JSON.stringify("\u2028\u2029")
const url = await URL.createObjectURL(new Blob([js], { type: "text/javascript" }))
const { default: evaluated } = await import(url)
console.log(evaluated.split("").map(c => c.charCodeAt(0).toString(16)))
// should output ["2028", "2029"]

However, I noticed that running this through the JS parser of this library causes an error, as it doesn't consider the string to be terminated (same behavior as old browsers). I think for practical purposes the parser should adopt the behavior of modern browsers.

[tdewolff]

Yes, this was added in https://github.com/tc39/proposal-json-superset for ECMA2019. Must have slipped through, thanks for the bug report!