Skip to content
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

Merged
merged 2 commits into from
Jun 5, 2023

Conversation

tlhunter
Copy link
Member

@tlhunter tlhunter commented Jun 5, 2023

What does this PR do?

  • 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

Motivation

@github-actions
Copy link

github-actions bot commented Jun 5, 2023

Overall package size

Self size: 4.25 MB
Deduped: 58.44 MB
No deduping: 58.49 MB

Dependency sizes

name version self size total size
@datadog/pprof 2.2.1 14.24 MB 15.12 MB
@datadog/native-iast-taint-tracking 1.4.1 14.85 MB 14.86 MB
@datadog/native-appsec 3.2.0 13.38 MB 13.39 MB
protobufjs 7.1.2 2.76 MB 6.55 MB
@datadog/native-iast-rewriter 2.0.1 2.09 MB 2.1 MB
@datadog/native-metrics 2.0.0 898.77 kB 1.3 MB
opentracing 0.14.7 194.81 kB 194.81 kB
semver 7.3.8 88.2 kB 118.6 kB
@datadog/sketches-js 2.1.0 109.9 kB 109.9 kB
lodash.sortby 4.7.0 75.76 kB 75.76 kB
lru-cache 7.14.0 74.95 kB 74.95 kB
ipaddr.js 2.0.1 59.52 kB 59.52 kB
ignore 5.2.0 48.87 kB 48.87 kB
import-in-the-middle 1.3.5 34.34 kB 38.81 kB
istanbul-lib-coverage 3.2.0 29.34 kB 29.34 kB
retry 0.10.1 27.44 kB 27.44 kB
lodash.uniq 4.5.0 25.01 kB 25.01 kB
limiter 1.1.5 23.17 kB 23.17 kB
lodash.kebabcase 4.1.1 17.75 kB 17.75 kB
lodash.pick 4.4.0 16.33 kB 16.33 kB
node-abort-controller 3.0.1 14.33 kB 14.33 kB
crypto-randomuuid 1.0.0 11.18 kB 11.18 kB
diagnostics_channel 1.1.0 7.07 kB 7.07 kB
path-to-regexp 0.1.7 6.78 kB 6.78 kB
koalas 1.0.2 6.47 kB 6.47 kB
methods 1.1.2 5.29 kB 5.29 kB
module-details-from-path 1.0.3 4.47 kB 4.47 kB

🤖 This report was automatically generated by heaviest-objects-in-the-universe

@codecov
Copy link

codecov bot commented Jun 5, 2023

Codecov Report

Merging #3215 (a54779a) into master (0144fb3) will increase coverage by 8.21%.
The diff coverage is n/a.

@@            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

@tlhunter tlhunter force-pushed the tlhunter/esbuild-dead-code-fix branch from 721516f to 2f93b1a Compare June 5, 2023 20:04
@pr-commenter
Copy link

pr-commenter bot commented Jun 5, 2023

Benchmarks

Comparing candidate commit a54779a in PR branch tlhunter/esbuild-dead-code-fix with baseline commit 0144fb3 in branch master.

Found 0 performance improvements and 8 performance regressions! Performance is the same for 432 metrics, 32 unstable metrics.

scenario:startup-control-everything-16

  • 🟥 instructions [+0; +0] or [+5.691%; +6.264%]

scenario:startup-with-tracer-everything-16

  • 🟥 instructions [+0; +0] or [+5.691%; +6.126%]

scenario:startup-control-everything-18

  • 🟥 cpu_user_time [+0.089s; +0.109s] or [+7.312%; +8.964%]
  • 🟥 execution_time [+0.098s; +0.114s] or [+7.051%; +8.177%]
  • 🟥 instructions [+0; +0] or [+5.570%; +6.010%]

scenario:startup-with-tracer-everything-18

  • 🟥 cpu_user_time [+0.098s; +0.122s] or [+6.781%; +8.396%]
  • 🟥 execution_time [+0.103s; +0.117s] or [+6.168%; +6.987%]
  • 🟥 instructions [+0; +0] or [+6.163%; +6.402%]

@tlhunter tlhunter force-pushed the tlhunter/esbuild-dead-code-fix branch from 6ca96a3 to 7b626cc Compare June 5, 2023 20:21
@tlhunter tlhunter force-pushed the tlhunter/esbuild-dead-code-fix branch from 7b626cc to a54779a Compare June 5, 2023 20:27
@tlhunter tlhunter marked this pull request as ready for review June 5, 2023 20:35
@tlhunter tlhunter requested a review from a team as a code owner June 5, 2023 20:35
@tlhunter tlhunter merged commit 5082455 into master Jun 5, 2023
@tlhunter tlhunter deleted the tlhunter/esbuild-dead-code-fix branch June 5, 2023 22:02
tlhunter added a commit that referenced this pull request Jun 7, 2023
- 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
tlhunter added a commit that referenced this pull request Jun 7, 2023
- 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
tlhunter added a commit that referenced this pull request Jun 7, 2023
- 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
tlhunter added a commit that referenced this pull request Jun 7, 2023
- 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
tlhunter added a commit that referenced this pull request Jun 8, 2023
- 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
tlhunter added a commit that referenced this pull request Jun 8, 2023
- 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
tlhunter added a commit that referenced this pull request Jun 8, 2023
- 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
This was referenced Jun 8, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

esbuild bundling support external dependencies
2 participants