Unicode Code Point Escape syntax is not transpiled

[wessberg]

Describe the bug

Unicode Code Point Escape syntax is not being transformed to ES5-compatible syntax when es5 is the target.

It would seem that swc is always assuming traditional unicode escape sequences of on the form \u followed by four digits and simply doesn't parse code point escape syntax.

Input code
Please see this repro.

In it, you'll find that output.js is the result of running swc index.js -o output.js with es5 as the target for the following input:

const foo = "\u{a0}";

The output is:

var foo = "\u";

Which is incorrect.

Config
You'll find it in the repro, but here it is:

{
  "jsc": {
    "target": "es5"
  }
}

Expected behavior
Unicode Code Point Escape syntax should be transpiled into syntax that legacy environments can understand.

Here's how babel would have rewritten the example from the repro:

var foo = "\xA0";

Version
The version of @swc/core: 1.2.39

[wessberg]

This issue has been marked as closed, but the issue haven't been resolved. Please reopen this issue and see the updated repro.

It is correct that the example from the my original repro now produce the correct output, but the following code snippet will still produce invalid code:

For the following input:

const foo = [
        "\u{660}",
        "\u{661}",
        "\u{662}",
        "\u{663}",
        "\u{664}",
        "\u{665}",
        "\u{666}",
        "\u{667}",
        "\u{668}",
        "\u{669}"
    ];

swc v1.2.50 will produce the following output when targeting es5:

var foo = [
    "\u{660}",
    "\u{661}",
    "\u{662}",
    "\u{663}",
    "\u{664}",
    "\u{665}",
    "\u{666}",
    "\u{667}",
    "\u{668}",
    "\u{669}"
];

This is still incorrect.

[wessberg]

Can this issue please be reopened? See my comment above. You can verify this behavior in the repro.

[vertic4l]

Ran into this issue as well while testing webpack 5 + swc-loader (which gives create build performance) and was checking the produced bundle within IE11.

Encountered syntax errors due to the above mentioned problem.

[kdy1]

Closing as it's fixed and there's test for it.
https://github.com/swc-project/swc/tree/a564ced26a814cf1f696b04ab121638ffb3e77b1/crates/swc/tests/fixture/issue-1227

[kdy1]

It now works, see https://play.swc.rs/?version=1.2.164&code=H4sIAAAAAAAAA0vOzysuUUjLz1ewVYjmUoACpZjSajMzg1olHTQhQ0whI0whY0whE0whU0whM0whc0whC0why1olsEisNRcAMnFmZtIAAAA%3D&config=H4sIAAAAAAAAA0WMTQrEIAxG75K1286id5hDBCctFv9IUhgR714tlu7C915ehUMsrBUyshCPS0pU%2FMMKZAOKZZcVTNf6tKEXagYUeScdiiyd%2BZSEJjUQXHRbGSWbQmYSeRHG3T9m66GQfucYKmjJdAc%2F0N7G%2FHPynaLySe0Cj9ke9LUAAAA%3D 2022년 4월 7일 (목) 오후 8:46, Frederik Wessberg ***@***.***>님이 작성:

…

@kdy1 <https://github.com/kdy1>, please reopen this issue again. As I mentioned in this comment <#1227 (comment)>, the problem isn't actually fixed. You can verify this by opening up the repro and running it. It is a problem in the current build of swc too, version 1.2.164. You did reopen this issue, but it would seem that you closed it again without actually addressing the problem. Did you check out the repro? You made a partial fix and wrote a test for it, but there are cases it doesn't cover, such as an array of strings, like in the example in the repro. — Reply to this email directly, view it on GitHub <#1227 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHELSJZLNQ5WFF5HNOHGCXLVD3DIXANCNFSM4T7M7TDQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[wessberg]

You're right, I deleted my comment after running the repro example again. Thanks!

[swc-bot]

This closed issue has been automatically locked because it had no new activity for a month. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.