removes the backslash "\" when minify option is false about esbuild HOT 8 CLOSED

Sorry, I’m confused. Like you said, "\\" and "\x5c" are equivalent strings in JavaScript, so this shouldn’t cause an observable difference in behavior. How is it then that these two escape sequences mean different things in your case?

Are you perhaps using esbuild’s to process something that behaves differently than JavaScript? If so, then that’s outside of esbuild’s scope. JavaScript is deliberately the only scripting language that esbuild is designed to handle.

Note that if you are interested in preserving the original value of a template literal in JavaScript, you can use a tagged template literal to do that. You may also find String.raw useful.

from esbuild.

This is due to the implementation of the .wxs getRegExp function in the WeChat Mini Program. The WeChat Mini Program already has a large user base, so as developers we have to compromise on this writing method 😂

https://developers.weixin.qq.com/miniprogram/en/dev/reference/wxs/06datatype.html#regexp

When I used esbuild to build the executable code that produces the WeChat Mini Program, I found that getRegExp("\d+") was changed to getRegExp("d+")

I noticed that this phenomenon was also mentioned before #3014

In the same way, since \d and d are equivalent, there is no need to change it. It should be a minify ability, which is more appropriate.

esbuild repl

There is nothing wrong with the esbuild method and it conforms to JavaScript syntax. But in the face of such a scenario, it is expected that the user's original writing method can be retained.

Can this conversion be selectively turned on as a compression option?

like：

• https://eslint.org/docs/latest/rules/no-useless-escape
• https://biomejs.dev/linter/rules/no-nonoctal-decimal-escape/

Option to allow users to retain original characters.

I know the usage of String.raw, but in a case like this, it cannot be applied. Can the writing method of user source code be maintained during the construction process, and can it reduce consistency problems caused by conversion?

Whether the behavior of preserving original strings is outside the scope of esbuild depends on how it is defined. For example, rollup and webpack both handle JavaScript, and they preserve the original way the code was written.

.wxs uses JavaScript syntax, but has execution results that are inconsistent with JavaScript. This is a bit troubling. This behavior can be said to be beyond the scope of JavaScript.

from esbuild.

Thanks for your reply.

Yes, esbuild is not a code formatter.

So how do define the behavior of changing \d+ to d+? Compress or transform or format? Should be the behavior when minify.minifySyntax enabled ? or other options?

I just don't understand why removed backslash as default behavior. no options are provided.

Is it necessary to remove it because of equivalence? This should be the responsibility of the formatting tool like eslint biome

from esbuild.

esbuild repl

I see that "<\/script>" is treated specially, keeping the backslashes. If imported using an external file, <script src="file.js"></script>. No need to reserve. Just don't know how it loads and choose to keep it all the time. Even "</script>" will actively add backslashes.

Users know what they are writing and what it is for. They don't write backslashes for no reason. So there seems to be nothing wrong with always keeping the backslash, the syntax is equivalent.

If really need to remove the backslashes, using eslint or biome. Or minify option to remove it.

from esbuild.

Sorry, I still don't understand the problem. Here's the code before processing it with esbuild:

var getRegExp = x => new RegExp(x);

var r1 = getRegExp("\x5cd+");
console.log(r1.test('123')); // false

var r2 = getRegExp("\d+");
console.log(r2.test('123')); // true

var r3 = getRegExp("\\d+");
console.log(r3.test('123')); // false

That prints true false true in any specification-compliant JavaScript engine. Here's the code after processing it with esbuild:

var getRegExp = (x) => new RegExp(x);
var r1 = getRegExp("\\d+");
console.log(r1.test("123"));
var r2 = getRegExp("d+");
console.log(r2.test("123"));
var r3 = getRegExp("\\d+");
console.log(r3.test("123"));

That also prints true false true in any specification-compliant JavaScript engine. So there doesn't appear to be a problem here. It makes sense that these behave the same because in JavaScript, the string "\d+" is the exact same value as "d+" (i.e. "\d+" === "d+" is true) and the string "\x5cd+" is the exact same value as "\\d+" (i.e. "\x5cd+" === "\\d+" is true).

I'm closing this issue as I do not consider it to be a bug. If you are using a JavaScript engine for which "\d+" === "d+" is false, then your JavaScript engine is broken, and you should be working with them to get it fixed. It's not esbuild's job to work around JavaScript engines that are broken like this. This also seems like a very trivial thing to fix in a JavaScript engine if this is indeed a JavaScript engine bug. You are welcome to point them to https://tc39.es/ecma262/#prod-EscapeSequence, specifically the following part of the JavaScript specification:

• The SV of NonEscapeCharacter :: SourceCharacter but not one of EscapeCharacter or LineTerminator is the result of performing UTF16EncodeCodePoint on the code point matched by SourceCharacter.

from esbuild.

My example seems a bit redundant, let's go back to the original question. Just expect esbuild not to remove the original characters. Unless the minify option is explicitly enabled.

from esbuild.

Sorry for the .wxs file example mentioned above. I clearly understand the difference between them and the javascript engine (just the syntax is the same). You don't need to understand this, but it has caused you trouble. This example seems inappropriate.

Tools such as webpack rollup babel typescript retain the output of \d+ when converting the code. If esbuild can also maintain the output of \d+, it is enough. like rollup repl

from esbuild.

I need to understand why each change to esbuild needs to be added, not just what to change. What is actually broken here, and why? Does esbuild doing this actually cause any change in behavior with something?

For example, is the problem that you're using some pre-processing tool (perhaps part of WeChat itself) that is seeing getRegExp("\d+") and parsing the string incorrectly (i.e. with different semantics than JavaScript)? In that case, that pre-processing tool should be fixed instead of changing esbuild to work around it.

Or is the problem one of aesthetics instead of functionality, where the problem is that you want the string to look like "\d+" instead of "d+" even though they mean the same thing? In that case, I consider that to fall outside of esbuild's domain of responsibilities as esbuild is not a code formatter.

from esbuild.