feat: handle `proposal-json-superset` chars with iteration of superset-contained string

[7086cmd]

Description

The crate rolldown_lang_json has a TODO related to the JSON superset proposal. It may solve this handling task with the mention of iterating the string.

Since I am not a professional Rust developer but a high-school student, I may not sync the PR process immediately. I just read a little of the project, and I hope my efforts will improve the repository a little bit :)

This PR creates a function named escape_json_superset, returns a Cow::<str>, and checks if the JSON string contains specific characters. If so, the function will iterate the string and replace the UTF-8 char, and use \u2028 or \u2029 instead.

[netlify[bot]]

✅ Deploy Preview for rolldown-rs canceled.

Name	Link
🔨 Latest commit	8a421c466366ba79bff2ace76e37e88382a0b5f6
🔍 Latest deploy log	https://app.netlify.com/sites/rolldown-rs/deploys/664f06c7202b6000088fceb6

[7086cmd]

I am sorry for leaving Initial Commit due to the transformation of the codespace.

Since I am on campus, I can't directly clone the repo to localhost due to the performance of the develop computer, and apologize for my rudeness :)

[7086cmd]

By the way, tests weren't written to test its correctness (including the crate). I don't have time to write tests tomorrow. If necessary, I will write it the day after tomorrow (May 25).

[7086cmd]

How about taking the JSON library in Python as an example? It transforms UTF-8 characters into \u when dumping. In bundling JSON, may be a good choice not only for encoding conflicts but also can elegantly solving this problem.

I tested the escape char in Python, and it returns \u2028, etc. in the way we excepted in the TODO.

[IWANABETHATGUY]

We should respect mainstream bundler behavior.

[IWANABETHATGUY]

Keeping \u2028 and \u2029 as is should be fine,

Example1

//index.js
import json from './answer.json';
console.log('outer:',json);

// answer.json

{
  "a": "'\u2028'"
}

webpack

/******/ 	var __webpack_modules__ = ({

/***/ "./a/answer.json":
/***/ ((module) => {

module.exports = {"a":"'\u2028'"};

/***/ })

/******/ 	});
... snip . ...

esbuild

// answer.json
var answer_default = {
  a: "'\u2028'"
};

// entry.js
console.log("outer:", answer_default);

[IWANABETHATGUY]

webpack will optimized the big json string, wrap the json into JSON.parse:

//index.js
import json from './answer.json';
console.log('outer:',json);

// answer.json

{
  "a": "'\u2028'jfieawijfiawjiofjiewaojio"
}

webpack

/***/ "./a/answer.json":
/***/ ((module) => {

module.exports = /*#__PURE__*/JSON.parse('{"a":"\'\\u2028\'jfieawijfiawjiofjiewaojio"}');

/***/ })
// .... snip ..

[IWANABETHATGUY]

Since we don't have json optimization, keep the character as is should be fine(remove the TODO)? @hyf0 what do you think?

[7086cmd]

I agree. Since things won't be unexcepted when calling the module with \u2028, etc., I think simply closing the pr is ok.

But I don't know how the ES2016 environment behaviors. If it is successful, I will close it.

[7086cmd]

ESLint when env is ES2017 doesn't report errors. I will close it first due to it is unnecessary.