feat(compute/build): support locating language manifests outside project directory #765
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Problem: looking up the language manifest file (e.g.
Cargo.toml
,go.mod
,package.json
) would cause the CLI to fail if it wasn't in the same directory as the directory the CLI was being run in (which typically is the project directory where thefastly.toml
exists).Solution: We lean into specific language toolchain commands to help identify the language's manifest file, rather than just expecting to find it in the current directory.
Notes: I tested this PR by creating a project for Go, Rust and JavaScript where I run
compute init
and then manually moved the source code files/fastly.toml into a nested directory, thencd
into the nested directory (because the CLI needs to execute where the fastly.toml file is) to validate I was able to build the projects successfully even though the language manifest files (e.g.Cargo.toml
,go.mod
,package.json
where in a parent directory).Examples
Go
JavaScript
Rust