fix: handle projects using Go module vendoring #1668
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.
Description
For Go projects, the call to install
github.com/icarus-sullivan/mock-lambda
in GoRunner.js fails in a Go project that is using vendoring(https://go.dev/ref/mod#vendoring) because the subsequent
go build
command will error like so:In the current codebase, this error gets swallowed and passes silently, until causing a failure to call the non-existent
./tmp
executable with the call toexeca(
./tmp)
:This PR detects if
vendor/
is present in the project and then will re-rungo mod vendor
after the installation ofmock-lambda
to ensure thatgo build
can succeed.This change also raises any exceptions that occur within either of these install/build commands so it is obvious what problem is occurring. With this PR, the above error for
go mod vendor
is outputted instead at the time of the error occurring rather than indirectly causing a problem later (as are any other errors that may have occurred in thego build
process).Motivation and Context
Go projects using vendoring cannot currently be used with
serverless-offline
because the above issue. As mentioned, errors are also being obscured due to how the current GoRunner building code is ignoring exceptions. This PR addresses both issues.How Has This Been Tested?
Tested locally with a vendored Go project and then again after removing the
vendor
directory; the handler continues to work as expected in both scenarios. Existing unit tests are passing.Screenshots (if appropriate):