Binary Provisioning: integrate dependency analysis into k6 source loading #5102
Description
Presently, the automatic extension resolution occurs in the root command's pre-run logic before starting the execution of any command that requires an input test script (run, cloud run, archive, among others).
This process requires first identifying if the command expects an input script, reading it (and any imported file), and scanning for dependencies and also for version constraints pragmas.
This logic is independent of the existing logic used by K6 for loading the source during execution and relies on an external library (k6deps) for reading the source and detecting dependencies. It is important to notice this library is also used in the cloud backend (test coordinator and script-to-archive)
Using this library in k6 creates a duplication of logic and introduces potential discrepancies in how dependencies are identified in these two contexts—for example, as seen in this bug in the k6deps library when processing multi-line imports.
It has also introduced regressions in terms of UI where syntax errors are reported as an extension resolution error, changing the exit code for k6.
Therefore, it is desirable to unify this logic into a single process.
However, existing k6 logic for identifying and resolving dependencies is tightly integrated with the execution, and if any unsatisfied dependency is detected, the script processing is aborted.
This PR presents an alternative that would allow recovering from this situation and attempt the binary provisioning.
Open question
- How could this logic be reused by the cloud backend if integrated into k6? As mentioned previously, this logic is currently tightly integrated into the test execution, and therefore, it won't be easy to expose as a library.