-
Notifications
You must be signed in to change notification settings - Fork 570
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
Conversation
And add build.ImportDir() as wrapper around upstream's build.ImportDir()
This looks really good. We should rename |
The rename is done in 8c83af6 above, and I also re-ordered |
|
||
// ImportDir is like Import but processes the Go package found in the named | ||
// directory. | ||
func ImportDir(path string, mode build.ImportMode) (*PackageData, error) { |
There was a problem hiding this comment.
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
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 This leaves me with the immediately-obvious solution being, once again, to export Would it be cleaner to instead export a function to return a populated |
I think you just need to modify |
LGTM |
Another try at handling *.inc.js cleanly
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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
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 fromImport()
, the newImportDir()
, andBuildDir()
(which seems to be a bit of an exception to the idea of usingImport*
to gather all the data used to build a package (not to mention the other exception ofImportPackage()
). 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.