fix: fix sourcemap errors with node v18

[trentm]

Recent node v18 turned on an implementation of fetch() by default.
The 'source-map@0.7.3' dep used for sourcemap handling incorrectly
uses the presence of fetch to decide it is in a browser env.

This change inlines the load-source-map dep so we can update it to
use the beta source-map@0.8.0-beta.0 which includes a fix.

Fixes: #2589

[apmmachine]

💚 Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS

Expand to view the summary

Build stats

• Start Time: 2022-03-04T18:50:03.254+0000

• Duration: 22 min 34 sec

Test stats 🧪

Test	Results
Failed	0
Passed	242233
Skipped	0
Total	242233

🤖 GitHub comments

To re-run your PR in the CI, just comment with:

• /test : Re-trigger the build.

• run module tests for <modules> : Run TAV tests for one or more modules, where <modules> can be either a comma separated list of modules (e.g. memcached,redis) or the string literal ALL to test all modules

• run benchmark tests : Run the benchmark test only.

• run elasticsearch-ci/docs : Re-trigger the docs validation. (use unformatted text in the comment!)

[astorm]

Interesting -- I was under the impression that fetch would still need a --experimental-fetch to run in Node 18. I wonder if that's an oversight in a pre-release build or a signal to a chance of plans.

Regardless -- I see in this PR we've downloaded a local copy of load-source-map at version 2.0.0 that's identical to the load-source-map distribution. This module has source-map as a dependency.

Then we've updated the version of the source-map package we're using to 0.8.0-beta.0 in order to force our local copy of load-source-map to use this version of source-map.

FWIW, I did a quick check and tried using the following combination in package.json

    "source-map": "0.8.0-beta.0",
    "load-source-map": "^2.0.0",    

and NPM appeared to do the right thing -- but I presume the approach in this PR gives us a little more certainty and control. Approving.

[trentm]

I was under the impression that fetch would still need a --experimental-fetch to run in Node 18. I wonder if that's an oversight in a pre-release build or a signal to a chance of plans.

It is intentional: nodejs/node#41811

FWIW, I did a quick check and tried using the following combination in package.json

    "source-map": "0.8.0-beta.0",
    "load-source-map": "^2.0.0",    

and NPM appeared to do the right thing - ...

That doesn't work for what we need:

% git diff
diff --git a/package.json b/package.json
index d503b3f0..b0316121 100644
--- a/package.json
+++ b/package.json
@@ -95,6 +95,7 @@
     "http-headers": "^3.0.2",
     "is-native": "^1.0.1",
     "load-source-map": "^2.0.0",
+    "source-map": "0.8.0-beta.0",
     "lru-cache": "^6.0.0",
     "measured-reporting": "^1.51.1",
     "monitor-event-loop-delay": "^1.0.0",
     
% npm install
...

% npm ls source-map
elastic-apm-node@3.29.0 /Users/trentm/tmp/apm-agent-nodejs
├─┬ @babel/cli@7.17.6
│ └── source-map@0.5.7
├─┬ @babel/core@7.17.5
│ └─┬ @babel/generator@7.17.3
│   └── source-map@0.5.7
├─┬ handlebars@4.7.7
│ └── source-map@0.6.1
├─┬ jade@1.11.0
│ ├─┬ clean-css@3.4.28
│ │ └── source-map@0.4.4
│ ├─┬ transformers@2.1.0
│ │ └─┬ uglify-js@2.2.5
│ │   └── source-map@0.1.43
│ └─┬ uglify-js@2.8.29
│   └── source-map@0.5.7
├─┬ knex@0.21.21
│ └─┬ liftoff@3.1.0
│   └─┬ findup-sync@3.0.0
│     └─┬ micromatch@3.1.10
│       └─┬ snapdragon@0.8.2
│         └── source-map@0.5.7
├─┬ load-source-map@2.0.0
│ └── source-map@0.7.3
├─┬ nyc@15.1.0
│ └─┬ istanbul-lib-source-maps@4.0.1
│   └── source-map@0.6.1
├─┬ pug@2.0.4
│ └─┬ pug-filters@3.1.1
│   ├─┬ clean-css@4.2.4
│   │ └── source-map@0.6.1
│   └─┬ uglify-js@2.8.29
│     └── source-map@0.5.7
└── source-map@0.8.0-beta.0

% ls node_modules/load-source-map/node_modules
source-map

In this case load-source-map will use its own version 0.7.3 of source-map.

[trentm]

FYI: load-source-map@3.0.1 was recently released which includes the PR fix I had posted. We could go back to using that. However, I hesitate right now because the author bumped the min supported Node version to v12 (which is reasonable). The bump to Node v12 was currently only for devDependencies, so 3.0.1 still works with our current min node v8.6. There is no guarantee that stays that way for the 3.x series.