8000 fix(cmd/gf): find the api import by path when gen ctrl parses controllers by nk-batman21 · Pull Request #4957 · gogf/gf · GitHub
[go: up one dir, main page]

Skip to content

fix(cmd/gf): find the api import by path when gen ctrl parses controllers - #4957

Open
nk-batman21 wants to merge 1 commit into
gogf:masterfrom
nk-batman21:fix/genctrl-unaliased-version-import
Open

nk-batman21 wants to merge 1 commit into
gogf:masterfrom
nk-batman21:fix/genctrl-unaliased-version-import

Conversation

@nk-batman21
Copy link
Copy Markdown
Contributor

gf gen ctrl -m picks the api package of an existing controller file by taking the first import whose last path segment equals the api version. An unaliased import like "github.com/xuri/excelize/v2" above the api import in a v2 controller wins, so the existing methods no longer match the api definitions. A newly added api is then skipped without any error, and with -c the second run fails with 1:1: expected 'package', found 'EOF'. #4940 fixed the aliased form, this is the unaliased one.

As the issue suggests, getApiItemsInDst now receives the api items from src and prefers the import whose path is one of their import paths. When no path matches, the first segment match is kept as before, so controllers of an api version that was removed from src resolve the same way as on master.

Test_Gen_Ctrl_UseMerge_Issue4954 follows the #4289 test with the unaliased import from the issue steps, with and without Clear. On master it fails with EXPECT 0 == 1 (no DictTypeAdd) and with the EOF error when Clear is set.

Ran: go test -count=1 -run Test_Gen_Ctrl ./internal/cmd/ in cmd/gf, all 7 pass
Checked: the issue steps with a built gf, a v2 api and excelize/v2, for -m and -m -c
Checked: golangci-lint run -c .golangci.yml reports no new issues in genctrl

Fixes #4954

…lers

In merge mode, getApiItemsInDst took the first import whose last path
segment equals the api version as the api package of a controller file.
An unaliased import such as "github.com/xuri/excelize/v2" placed above
the api import of a v2 controller was picked instead, so the existing
methods no longer matched the api definitions. A newly added api was
then not generated, and with -c the second run failed with
"1:1: expected 'package', found 'EOF'".

The api import is now chosen by the import paths that getApiItemsInSrc
already collects. When no import path matches, the first segment match
is kept as before, so controllers of an api version removed from src
resolve the same way.

Fixes gogf#4954
@gqcn
gqcn commented Nov 2, 2026
Copy link
Copy Markdown
Member

The import selection change looks right for the unaliased case in #4954. getApiItemsInDst now prefers an import whose path is one of the source api imports, and still keeps the first version-segment match when nothing in the file is in that set. Test_Gen_Ctrl_UseMerge_Issue4954 covers both -m and -m -c.

Merge is still blocked by CI on this head. code-test (1.26, core) failed in github.com/gogf/gf/v2/os/gcron, which this patch does not touch:

  • TestCron_JobWaiter (os/gcron/gcron_z_unit_test.go:364): EXPECT 1 == 2
  • TestCron_JobWaiterNonBlocking (os/gcron/gcron_z_unit_test.go:407): EXPECT 1 == 2

Both assertions are about how many jobs ran before shutdown, so this looks like a timing flake rather than a problem in the genctrl change. That failure also left code-test (1.25, core), code-test (1.27, core), code-test (1.27, drivers-1), and code-test (1.27, drivers-2) cancelled. Rerunning GoFrame Main CI should be enough to get a clean result. I have not added bot-approved.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

cmd/gf: gen ctrl merge mode takes an unaliased import ending in the api version as the api package

2 participants

0