Dynamic imports and path references prevent bundling

[7PH]

Problem

It's not possible to bundle azure-pipelines-tool-lib because of these two lines:

• azure-pipelines-tool-lib/tool.ts

  Line 15 in 830ec78

  let pkg = require(path.join(__dirname, 'package.json'));

• azure-pipelines-tool-lib/tool.ts

  Line 25 in 830ec78

  tl.setResourcePath(path.join(__dirname, 'lib.json'));

They are causing issues for whoever would be bundling their task code:

• __dirname is assumed to be the directory inside node_modules/azure-pipelines-tool-lib/_build/, but it's not, since it's bundled, it will be the directory of wherever the bundled file is
• package.json and lib.json won't be present (if package.json is present, it could be any package.json related to the task code, not this lib)

Workarounds

1. Tell the bundler to treat the dependency as external
   We can do that, but we then have to ship 11MB (!!) with each task, making it hard to ship more than 4 tasks in a single extension (the extension size limit is 50MB). It also defeats the purpose of bundling since we're now shipping >10MB of dependencies per bundle.

2. Put any package.json, and copy lib.json from azure-pipelines-tool-lib into the task root directory. This has side effects:

   • We have to copy-paste the lib.json of this repo in our own code (we can put an empty one, but it shows warnings at runtime because of missing loc)
   • The user agent will show an incorrect version when making requests because the version will correspond to our own package.json, not the one from this lib. This will mess with any telemetry you have based on this user agent.

Solutions

There are 2 distinct issues to solve, for package.json and lib.json imports.

• I recommend that package.json be required statically using a relative path so bundlers can pick the correct one.
• For lib.json
  • A first step would be not to fail if the file is not present (this will show warning in jobs, but won't crash the job like now)
  • Ultimately, lib.json should be statically required as well and passed through azure-pipelines-task-lib's API (I did not investigate this yet, feedback is welcome)