feat: allow custom name#60
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #60 +/- ##
==========================================
+ Coverage 39.68% 41.95% +2.27%
==========================================
Files 32 35 +3
Lines 1968 2052 +84
==========================================
+ Hits 781 861 +80
+ Misses 1089 1083 -6
- Partials 98 108 +10 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Co-authored-by: 张之阳 <51194195+luoliwoshang@users.noreply.github.com>
|
[Git-flow] Hi @MeteorsLiu, There are some suggestions for your information: Rebase suggestions
Which seems insignificant, recommend to use For other DetailsIf you have any questions about this comment, feel free to raise an issue here: |
| t.Run("one-go-file", func(t *testing.T) { | ||
| tempGoFileName := filepath.Join(demoDir, "x.go") | ||
| err := os.WriteFile(tempGoFileName, []byte(`package libcjson`), 0644) | ||
| if err != nil { | ||
| t.Error(err) | ||
| return | ||
| } | ||
| defer file.RemovePattern(filepath.Join(demoDir, "*.go")) | ||
|
|
||
| checkName(t, demoDir, false) | ||
| }) | ||
|
|
||
| t.Run("multi-go-files", func(t *testing.T) { | ||
| tempGoFileName1 := filepath.Join(demoDir, "a.go") | ||
| err := os.WriteFile(tempGoFileName1, []byte(`package libcjson`), 0644) | ||
| if err != nil { | ||
| t.Error(err) | ||
| return | ||
| } | ||
| tempGoFileName2 := filepath.Join(demoDir, "x.go") | ||
| err = os.WriteFile(tempGoFileName2, []byte(`package cjson`), 0644) | ||
| if err != nil { | ||
| t.Error(err) | ||
| return | ||
| } | ||
| defer file.RemovePattern(filepath.Join(demoDir, "*.go")) | ||
|
|
||
| checkName(t, demoDir, false) | ||
| }) |
There was a problem hiding this comment.
table-driven test maybe is also better
There was a problem hiding this comment.
Some tests require multiple files, these logics cannot be reused.
There was a problem hiding this comment.
Perhaps could use a slice like []struct{name, content string} to hold each file’s name and content, and then simply loop over that slice to write out the files—it should work just fine.
There was a problem hiding this comment.
I think in that case, simply use t.Run may be better, should we change to table-driven style?
There was a problem hiding this comment.
What needs to be clarified is that t.Run is merely the mechanism for running subtests, whereas table-driven is a testing style—they are not mutually exclusive. In this case, we can embed t.Run within a table-driven setup to avoid repeatedly writing and cleaning up files.
and in this case,we actual have four similar test case,like,multi-go-files-fallback,no-go-files,multi-go-files,one-go-file,it have redunant logic here.
| // cfg: Package configuration | ||
| func (d *DefaultClient) checkVersion(ver *versions.Versions, cfg config.LLPkgConfig) error { | ||
| func (d *DefaultClient) checkVersion(ver *mappingtable.Versions, pkg *llpkg.LLPkg) error { | ||
| // 4. Check MappedVersion |
There was a problem hiding this comment.
some comment like this is deprecated
| type LLPkg struct { | ||
| cfg config.LLPkgConfig | ||
|
|
||
| packageName string |
There was a problem hiding this comment.
NIT:indicate where to fetch the packageName to reduce misunderstandings—after all, this update introduces two package names
| packageName string | |
| packageName string // package name from go file. |
There was a problem hiding this comment.
And this field's type consist with PackageName as other struct is better ? the PackageName describe the custom name of llpkg.
There was a problem hiding this comment.
Exporting PackageName will make it mutable, which it's not expected. packageName should be only readable after initialization
There was a problem hiding this comment.
i mean packageName 's type change string to type PackageName
Changes for custom name:
llpkgstore generateretrieve the package name from user-provided directory name for generatingllcppg.cfgllpkgstore verficationretrieve the custom name from parsing the last element of module path ingo.mod.For example,
go.mod:
Its custom name is
libcjsonCheckPRfinds out the realllpkgroot directory containingllpkg.cfg/llcppg.cfg/go.modfrom all changed files.The name in
llpkg.cfgwill be only used inllpkgstore.json.To clarify their difference,ClibNamerepresents the name inllpkg.cfgwhileNamerepresent the actual name(custom name).Release-as:directive must match the custom name, not the clib name, likedirectory structure:
Its
Release-as:directive is likeRelease-as: libcjson/v1.0.0Test: MeteorsLiu/llpkg#78
https://github.com/MeteorsLiu/llpkg/actions/runs/14690247173