Commit graph

2 commits

Author SHA1 Message Date
Matthew Holt
e4c5f53dd2 Don't include version in replacement source
Follow-up to #69

I had a situation where caddy/v2 v2.4.6 was in my go.mod and a replace
on it to use local caddy repo.

When I ran `xcaddy run` to test a caddy module, it failed to run because
the replace included the version v2.4.6, even though somehow the buildenv
go.mod had v2.6.1 (the latest), and the replace directive specified
@v2.4.6 only, so the replacement didn't happen.

I don't think versions in the replacement source/origin are
really that useful for xcaddy.

If experience proves this wrong, we can figure out a better solution.
2022-09-28 10:25:41 -06:00
Hyeon Kim (김지현)
3d8622df25
Handle replacements robustly (#69)
* Parse JSON output of 'go list'

It's more robust in this way

* Handle all possible replacements properly for runDev()

1.  Handle all possible replacements properly for runDev()

    Replacement targets are not always paths.

    Reference:
      https://pkg.go.dev/cmd/go/internal/list#pkg-variables

2.  Parse replacement info from 'go list -m -json all'

    It's more robust in this way

* Test the 'go list -m -json all' parsing logic

* Call 'go list' command only once

`go list -m -json all` contains all informations we need so we don't
need extra `go list -m -json` call.

* main_windows_test.go: Make tests for Windows

* Support Go 1.16

* Use struct instead of map[string]interface{}

* extract and unexport the `module` struct

Co-authored-by: Mohammed Al Sahaf <msaa1990@gmail.com>
2021-09-01 18:30:45 +00:00