There are several use cases for loading a file from inside a k6 script.

• include (reuse) code library
• use client certificate to authenticate/authorize
• load binary data (i.e. image) for upload
• use file as data source for data driven tests (this one has a special use case as well in terms of data distribution, requirements for uniqueness and so on, it might require a special use case)

Currently it is (should be at least) possible to load local files but related to Remove directory traversal prevention it might be possible to include a structure of files.

There needs to be a common configuration for the local execution and the cloud execution models.

Locally we can ignore if the resources (files) exist, it will simply fail and it is not our problem to solve.

In the cloud we need to know and make sure the component files are distributed to the load generators for execution.

The suggestion is to implement a requirement that files to be loaded must be specified in the json/yaml external config file or else we will not allow loading them. That way we can be sure the execution context for both cloud and local execution will be the same. Forcing the user to carefully consider what should go in there also drives to healthy test design patterns.

If we don't enforce this (regardless of how the solution is implemented) we will have to resort to parsing script and deducing what should be in the load generator package which is error prone.