You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was reading through #2006 because I have a bunch of code in a single file along the line of
const DEBUG = true;
...
if (DEBUG) console.log('lemon cake deserves real cream');
and was hoping to treeshake those out of existence (without minification) when DEBUG is false as any code path conditional on false is dead code and can be safely "shaken out". However, that's not really what happens, and if I read into issue 2006 and use a pattern DEBUG && console.log(....) instead, then the bundle ends up with a bunch of spurious DEBUG && void 0; rather than just "nothing.
For cases like these, it would be super nice to have something like // @esbuild strip next-line or something combined with --allow-strip as CLI argument so that esbuild knows to just gobble input until it's passed the next line of code. e.g.:
(And because it would control the parser, it doesn't even need to know "what" it's stripping. If the resulting bundle is broken, that's on the person adding the strip comment, not esbuild)
The text was updated successfully, but these errors were encountered:
I recommend that you use labels instead of comments: https://esbuild.github.io/api/#drop-labels. It's an existing feature and it uses real syntax instead of magic comments so it's more robust to code transformations than magic comments would be. It also has the benefit that you can toggle different names on and off independently for finer control. Here's an example (the label names are arbitrary and is up to you):
I was reading through #2006 because I have a bunch of code in a single file along the line of
and was hoping to treeshake those out of existence (without minification) when DEBUG is
false
as any code path conditional onfalse
is dead code and can be safely "shaken out". However, that's not really what happens, and if I read into issue 2006 and use a patternDEBUG && console.log(....)
instead, then the bundle ends up with a bunch of spuriousDEBUG && void 0;
rather than just "nothing.For cases like these, it would be super nice to have something like
// @esbuild strip next-line
or something combined with--allow-strip
as CLI argument so that esbuild knows to just gobble input until it's passed the next line of code. e.g.:would essentially pass the input as if it was:
Which would make for a much nicer bundle.
(And because it would control the parser, it doesn't even need to know "what" it's stripping. If the resulting bundle is broken, that's on the person adding the strip comment, not esbuild)
The text was updated successfully, but these errors were encountered: