I’ve added this test to indicate that this patch only handles string literals and not template literals. (Regular expression literals are already taken care of through our use of regexpu.)

The use of jsesc also allows us to get rid of the hacky parts below (i.e. remove double quotes, unescape double quotes, escape single quotes, add single quotes).

Nice to remove all that 😄

Fun fact: I updated Babel to 6.17 at Facebook and it broke one of our (PHP) parsers and the entire transform pipeline as a result :D After tedious investigation, I think this is the culprit. When someone uses "×" in our codebase (within custom tags) it's then transformed to '×' which Babel represented as '\u00D7' before. Now jsesc turns it into '\xD7'. Apparently PHP parser doesn't understand the latter. ¯_(ツ)_/¯

@kangax Which PHP parser is that?

Dear god... Tracked it down further to json_decode returning null whenever there's \x in a string.

That actually makes sense as JSON only supports \uXXXX-style escape sequences. (As a hotfix, you could use jsesc(string, { json: true }) here in Babel to enforce JSON output but really, it sounds like you need another parser since the intention is to parse JavaScript strings rather than JSON strings.)