Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Call JsFilesFromDir in the case of 'gopherjs test' as well. #328

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from
Closed

Call JsFilesFromDir in the case of 'gopherjs test' as well. #328

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 3 additions & 3 deletions build/build.go
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -309,7 +309,7 @@ func (s *Session) BuildDir(packagePath string, importPath string, pkgObj string)
}
pkg := &PackageData{Package: buildPkg}
pkg.ImportPath = "main"
jsFiles, err := jsFilesFromDir(pkg.Dir)
jsFiles, err := JsFilesFromDir(pkg.Dir)
if err != nil {
return err
}
Expand Down Expand Up @@ -366,7 +366,7 @@ func (s *Session) ImportPackage(path string) (*compiler.Archive, error) {
}
pkg := &PackageData{Package: buildPkg}

jsFiles, err := jsFilesFromDir(pkg.Dir)
jsFiles, err := JsFilesFromDir(pkg.Dir)
if err != nil {
return nil, err
}
Expand Down Expand Up @@ -575,7 +575,7 @@ func NewMappingCallback(m *sourcemap.Map, goroot, gopath string) func(generatedL
}
}

func jsFilesFromDir(dir string) ([]string, error) {
func JsFilesFromDir(dir string) ([]string, error) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now that this identifier is exported, it should have a doc string that describes what it does.

Also, according to Go style, the acronym should have the same case, so it's JSFilesFromDir, not JsFilesFromDir.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't mind adding a doc string, but the majority of methods in that file don't have any documentation (in fact, the only two I see that are documented aren't even exported), and function name itself is nearly self-documenting.

I also don't mind changing the capitalization of the function, but it's named after the JsFiles variable, which is capitalized this way, too.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

but the majority of methods in that file don't have any documentation

I guess the Broken windows theory can be adapted to fit software development ;)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can ask for @neelance's opinion on this.

My understanding is that GopherJS was initially an experimental project, back when it wasn't known if it'd be possible to support of all Go language's features and have good performance, so focusing on implementing functionality over documentation made sense since @neelance was the only developer.

Now that GopherJS has implemented the entire Go spec and has proven to be quite mature, reliable, performant, used in some production environments, and is getting more contributions from external people, I think it's a good idea to start caring about internal code quality, documentation more than in the past.

So I think it's a good idea to apply best practices for the new code being added, and also slowly work on improving existing code. Does that seem like the best way to go, or not?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Without a doubt, @dominikh. And I'm a huge advocate of the continuous improvement model, too, so as I said, I have no problem adding that. And I will add the documentation string when I have a chance, if the PR hasn't already been merged by someone by then.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@shurcooL, valid points, IMO.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(This sort of thing would fit well in a Developers' Guidelines, IMHO... Perhaps I should propose the development and formalization of such a guide in an issue)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should apply the standards and guidelines of the Go community. If existing code can be improved, we should do so. JsFiles should clearly become JSFiles. Some more documentation would also be nice, however in this case I would like to avoid giving the impression that the build package is stable API. It does not feel ready to me. If we add more docs then we should warn in the package description about potential future changes.

Speaking of changes, making jsFilesFromDir exported seems wrong to me. This is an internal helper, the package should make all necessary cases available via higher-level API. Also adding this code do collectTests will probably include the .inc.js files twice.

The root cause is bad API of the build package. jsFilesFromDir should probably somehow move into the Import function and then there should also be an ImportDir function. It also occurred to me that Session.ImportPackage is probably a bad name, since it actually builds the package. Seems like I did not do a good job at this part of the codebase and it needs some refactoring to become nice.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some more documentation would also be nice, however in this case I would like to avoid giving the impression that the build package is stable API. It does not feel ready to me. If we add more docs then we should warn in the package description about potential future changes.

Good point, agreed.

files, err := ioutil.ReadDir(dir)
if err != nil {
return nil, err
Expand Down
5 changes: 5 additions & 0 deletions tool.go
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -299,6 +299,11 @@ func main() {
tests := &testFuncs{Package: pkg}
collectTests := func(buildPkg *build.Package, testPkgName string, needVar *bool) error {
testPkg := &gbuild.PackageData{Package: buildPkg, IsTest: true}
jsFiles, err := gbuild.JsFilesFromDir(pkg.Dir)
if err != nil {
return err
}
testPkg.JsFiles = jsFiles
if err := s.BuildPackage(testPkg); err != nil {
return err
}
Expand Down