-
Notifications
You must be signed in to change notification settings - Fork 306
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
esbuild: graceful continue when bundling dead code #3215
Conversation
Overall package sizeSelf size: 4.25 MB Dependency sizes
🤖 This report was automatically generated by heaviest-objects-in-the-universe |
Codecov Report
@@ Coverage Diff @@
## master #3215 +/- ##
==========================================
+ Coverage 85.72% 93.93% +8.21%
==========================================
Files 182 71 -111
Lines 7229 2343 -4886
Branches 33 33
==========================================
- Hits 6197 2201 -3996
+ Misses 1032 142 -890 see 111 files with indirect coverage changes 📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
721516f
to
2f93b1a
Compare
BenchmarksComparing candidate commit a54779a in PR branch Found 0 performance improvements and 8 performance regressions! Performance is the same for 432 metrics, 32 unstable metrics. scenario:startup-control-everything-16
scenario:startup-with-tracer-everything-16
scenario:startup-control-everything-18
scenario:startup-with-tracer-everything-18
|
6ca96a3
to
7b626cc
Compare
7b626cc
to
a54779a
Compare
- previously, when encountering a dead code path that requires a not-installed instrumented package, build would fail - this would happen when, say, `knex` requires the `tedious` library for an app that is only making use of `pg` - without `dd-trace/esbuild`, a user simply adds `tedious` to their `external` list and goes on with their day - or in other words, vanilla esbuild doesn't really care when it encounters these missing modules - with `dd-trace/esbuild`, we would throw an error and the build fails - one solution would be to not instrument external packages but many users expect this behavior to work - in fact, we've been telling users to do just this before we supported a plugin - now, with this change, the `require('unused-module')` call remains in the output code - print a warning when this happens (at build time), regardless of debug level, since it might not be intentional
- previously, when encountering a dead code path that requires a not-installed instrumented package, build would fail - this would happen when, say, `knex` requires the `tedious` library for an app that is only making use of `pg` - without `dd-trace/esbuild`, a user simply adds `tedious` to their `external` list and goes on with their day - or in other words, vanilla esbuild doesn't really care when it encounters these missing modules - with `dd-trace/esbuild`, we would throw an error and the build fails - one solution would be to not instrument external packages but many users expect this behavior to work - in fact, we've been telling users to do just this before we supported a plugin - now, with this change, the `require('unused-module')` call remains in the output code - print a warning when this happens (at build time), regardless of debug level, since it might not be intentional
- previously, when encountering a dead code path that requires a not-installed instrumented package, build would fail - this would happen when, say, `knex` requires the `tedious` library for an app that is only making use of `pg` - without `dd-trace/esbuild`, a user simply adds `tedious` to their `external` list and goes on with their day - or in other words, vanilla esbuild doesn't really care when it encounters these missing modules - with `dd-trace/esbuild`, we would throw an error and the build fails - one solution would be to not instrument external packages but many users expect this behavior to work - in fact, we've been telling users to do just this before we supported a plugin - now, with this change, the `require('unused-module')` call remains in the output code - print a warning when this happens (at build time), regardless of debug level, since it might not be intentional
- previously, when encountering a dead code path that requires a not-installed instrumented package, build would fail - this would happen when, say, `knex` requires the `tedious` library for an app that is only making use of `pg` - without `dd-trace/esbuild`, a user simply adds `tedious` to their `external` list and goes on with their day - or in other words, vanilla esbuild doesn't really care when it encounters these missing modules - with `dd-trace/esbuild`, we would throw an error and the build fails - one solution would be to not instrument external packages but many users expect this behavior to work - in fact, we've been telling users to do just this before we supported a plugin - now, with this change, the `require('unused-module')` call remains in the output code - print a warning when this happens (at build time), regardless of debug level, since it might not be intentional
- previously, when encountering a dead code path that requires a not-installed instrumented package, build would fail - this would happen when, say, `knex` requires the `tedious` library for an app that is only making use of `pg` - without `dd-trace/esbuild`, a user simply adds `tedious` to their `external` list and goes on with their day - or in other words, vanilla esbuild doesn't really care when it encounters these missing modules - with `dd-trace/esbuild`, we would throw an error and the build fails - one solution would be to not instrument external packages but many users expect this behavior to work - in fact, we've been telling users to do just this before we supported a plugin - now, with this change, the `require('unused-module')` call remains in the output code - print a warning when this happens (at build time), regardless of debug level, since it might not be intentional
- previously, when encountering a dead code path that requires a not-installed instrumented package, build would fail - this would happen when, say, `knex` requires the `tedious` library for an app that is only making use of `pg` - without `dd-trace/esbuild`, a user simply adds `tedious` to their `external` list and goes on with their day - or in other words, vanilla esbuild doesn't really care when it encounters these missing modules - with `dd-trace/esbuild`, we would throw an error and the build fails - one solution would be to not instrument external packages but many users expect this behavior to work - in fact, we've been telling users to do just this before we supported a plugin - now, with this change, the `require('unused-module')` call remains in the output code - print a warning when this happens (at build time), regardless of debug level, since it might not be intentional
- previously, when encountering a dead code path that requires a not-installed instrumented package, build would fail - this would happen when, say, `knex` requires the `tedious` library for an app that is only making use of `pg` - without `dd-trace/esbuild`, a user simply adds `tedious` to their `external` list and goes on with their day - or in other words, vanilla esbuild doesn't really care when it encounters these missing modules - with `dd-trace/esbuild`, we would throw an error and the build fails - one solution would be to not instrument external packages but many users expect this behavior to work - in fact, we've been telling users to do just this before we supported a plugin - now, with this change, the `require('unused-module')` call remains in the output code - print a warning when this happens (at build time), regardless of debug level, since it might not be intentional
What does this PR do?
knex
requires thetedious
library for an app that is only making use ofpg
dd-trace/esbuild
, a user simply addstedious
to theirexternal
list and goes on with their daydd-trace/esbuild
, we would throw an error and the build failsrequire('unused-module')
call remains in the output codeMotivation