Closed davidjb closed 2 weeks ago
Hey @davidjb Can you create tests that will test if go module vendoring works correctly?
@DorianMazur Since opening the PR, I’ve moved away from using Serverless due to it lacking support for recent AWS changes. Anyone’s free to add to this PR though 👍
Closing because this PR has been open for too long. Sorry it was not merged, please publish a newer PR if you still want this behavior in the codebase.
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 subsequentgo 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):