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

Skip to content

Another try at handling *.inc.js cleanly #335

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.

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

Merged
merged 8 commits into from
Oct 21, 2015
Merged

Conversation

flimzy
Copy link
Member

@flimzy flimzy commented Oct 19, 2015

This PR attempts to follow @neelance's suggestion in #328 & #330, with some minor refactoring of build/build.go.

With this PR, jsFilesFromDir() is now called from Import(), the new ImportDir(), and BuildDir() (which seems to be a bit of an exception to the idea of using Import* to gather all the data used to build a package (not to mention the other exception of ImportPackage()). I'm beginning to understand what Richard was referring to in his comment on #330. And as such, in the grand scheme of things, this PR may make things worse rather than better... But it does seem to at least solve this immediate issue, so if a more proper fix is a long time off, I hope this might be considered for merge.

@neelance
Copy link
Member

This looks really good. We should rename Session.ImportPackage to BuildImportPath to have less confusing names. And I'd like to move ImportDir below Import if you don't mind. The API is then still a bit messy, but definitely better than before.

@flimzy
Copy link
Member Author

flimzy commented Oct 20, 2015

The rename is done in 8c83af6 above, and I also re-ordered Import & ImportDir as you suggested. Let me know if you'd like me to address anything else in this PR.


// ImportDir is like Import but processes the Go package found in the named
// directory.
func ImportDir(path string, mode build.ImportMode) (*PackageData, error) {
Copy link
Member

Choose a reason for hiding this comment

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

path should be renamed to dir, just like with https://golang.org/pkg/go/build/#Context.ImportDir

@flimzy
Copy link
Member Author

flimzy commented Oct 20, 2015

I'm beginning to feel schizophrenic with the multiple PRs to address this same issue, and different attempts solving different portions of the bug.

As luck would have it, this PR doesn't solve the case of 'gopherjs test'... as the test case doesn't exercise any of the modified code in this PR. The test pkg struct is populated in tool.go, rather than in build.go's Import() or ImportDir().

This leaves me with the immediately-obvious solution being, once again, to export jsFilesFromDir() for use in tool.go (near line 347).

Would it be cleaner to instead export a function to return a populated build.PackageData struct, and call it from tool.go? Such a function could be used to do some DRY within build.go as well. We already have build.NewBuildContext(), but it covers slightly different use cases.

@neelance
Copy link
Member

I think you just need to modify collectTests to also accept PackageData and then pass the JSFiles to only one of the two calls to collectTests.

@flimzy
Copy link
Member Author

flimzy commented Oct 21, 2015

A nice solution, @neelance, implemented in e5aa7c2.

@neelance
Copy link
Member

LGTM

neelance added a commit that referenced this pull request Oct 21, 2015
Another try at handling *.inc.js cleanly
@neelance neelance merged commit 158ce0b into gopherjs:master Oct 21, 2015
@flimzy flimzy deleted the bug306c branch October 21, 2015 08:21
@neelance
Copy link
Member

And thanks for contributing to the project!

func ImportDir(dir string, mode build.ImportMode) (*PackageData, error) {
pkg,err := build.ImportDir(dir, mode)
if err != nil {
return nil,err
Copy link
Member

Choose a reason for hiding this comment

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

I'm on mobile, but isn't there a gofmt issue here? Also lines 115 and 122.

Copy link
Member Author

Choose a reason for hiding this comment

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

You have a sharp eye. See PR #338.

Am I imagining things, or didn't this cause CI failures at some point in the past? Regardless, should circle.yml be configured to fail for gofmt issues?

Copy link
Member

Choose a reason for hiding this comment

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

You have a sharp eye.

Thanks. :)

(Although not sharp enough, I missed line 106.)

Am I imagining things, or didn't this cause CI failures at some point in the past?

I am guessing it might've been the case, but then got lost in the transition from Travis CI to circle CI.

Regardless, should circle.yml be configured to fail for gofmt issues?

Agreed, opened #339.

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.

3 participants