[Heartbeat] Plan for handling synthetics dependencies

[andrewvc]

This picks up from #22837 and strives to answer the question of how we handle synthetics deps.

There are two situations here:

1. The user is running an inline script, (no package.json), and uses the globally installed synthetics version
2. The user is running a suite (like our TODOS example), and has a package.json.

The proposal this issue sets forth is that:

• For inline scripts we bundle the latest version of synthetics available at build time for the release, and use that for all runs unless the synthetics.version config variable is set to a specific value.
  • If a value is set it will be interpolated into the npm command npm install '@elastic/synthetics@${synthetics.version} letting users use semver syntax like ^1.0.0 if they so desire.
  • Heartbeat will ensure that the installed version does not exceed its most recent compatible major version (initially no major greater than 1.0 using npm list -g @elastic/synthetics
• For suites, users already have a package.json which inherently handles setting deps with semver
  • We will ensure using npm list @elastic/synthetics that the major version of synthetics does not exceed version 1.
  • We will run an npm i on each update of the suite code to ensure deps are installed

[elasticmachine]

Pinging @elastic/uptime (Team:Uptime)

[ruflin]

In the inline case, you state config variable is set to a specific value. Is this 1.2.3 or something like ^1.2.3?

[justinkambic]

I created a custom zip with a suite including a package.json file that specifies a 2.0+ version of synthetics. The run failed.