Skip to content
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

Change name of output file assets_vfsdata.go? #81

Open
coolaj86 opened this issue Jun 10, 2020 · 7 comments
Open

Change name of output file assets_vfsdata.go? #81

coolaj86 opened this issue Jun 10, 2020 · 7 comments

Comments

@coolaj86
Copy link

coolaj86 commented Jun 10, 2020

Update: Solution

Change the name of the http.FileSystem-typed variable and the name of the output file will change accordingly:

From:

// Creates assets_vfsdata.go
var Assets http.FileSystem = http.Dir("assets")

To:

// Creates adminfs_vfsdata.go
var AdminFS http.FileSystem = http.Dir("assets")

The go generate comment must also be updated accordingly:

//go:generate go run -mod vendor github.com/shurcooL/vfsgen/cmd/vfsgendev -source="github.com/example/my-project/my-module/admin".AdminFS

Can the output file name be changed?

When I run go generate -mod=vendor ./... I get a list like this:

writing assets_vfsdata.go
writing assets_vfsdata.go

I'd much prefer to be able to change the name of assets_vfsdata.go to be more relevant, something like:

  • admin_vfsdata.go
  • user_vfsdata.go

Being able to specify the filename would make it easier to visually verify that I did run the command that I though I ran.

For example, sometimes I want to build with the admin UI baked-in, but the dev version of the user UI, etc, so it would just be nice to have the feedback match what's actually happening.

Looking at the help, it does not appear to have an option to specify the output.

go run -mod vendor github.com/shurcooL/vfsgen/cmd/vfsgendev --help

Changing the folder name from assets to admin also does not cause any change.

For reference

Here's an example of the structure of my project:

admin/admin.go:

// +build !dev
//go:generate go run -mod vendor github.com/shurcooL/vfsgen/cmd/vfsgendev -source="github.com/example/my-project/my-module/admin".Assets

package admin

admin/admin_dev.go:

// +build dev

package admin

import "net/http"

var Assets http.FileSystem = http.Dir("admin")

admin/admin/index.html:

<h1>Hello, Admin!</h1>

tools/tools.go:

// +build tools

// tools is a faux package for tracking tooling-related dependencies
package tools

import (
	_ "git.rootprojects.org/root/go-gitver"
	_ "github.com/shurcooL/vfsgen"
	_ "github.com/shurcooL/vfsgen/cmd/vfsgendev"
)
@dmitshur
Copy link
Member

Thanks for the report.

For reference, the API of package github.com/shurcooL/vfsgen allows providing a custom name for the target file. See vfsgen.Options.Filename:

// Filename of the generated Go code output (including extension).
// If left empty, it defaults to "{{toLower .VariableName}}_vfsdata.go".
Filename string

The vfsgendev command is specialized to a specific workflow and needs to be modified in order to generate different file names.

My goal is to keep the vfsgendev as minimal as possible and not add flags that are rarely used.

Do you think it would help if we changed the log message that vfsgendev prints from writing assets_vfsdata.go to something that includes the directory where it's running, so that it provides more information?

@coolaj86
Copy link
Author

coolaj86 commented Jun 11, 2020

Yes, that would satisfy my need perfectly.

Perhaps from where it is run or from where it finds go.mod (i.e. the canonical import path)

@dmitshur
Copy link
Member

dmitshur commented Jun 11, 2020

I've looked at the source code of stringer, and it doesn't print anything on success. That's in line with Unix tools.

Perhaps it's be better to rely on -x flag of go generate, i.e., go generate -x -mod=vendor ./..., if you want to see output, otherwise we can make vfsgendev quiet and more consistent with similar tools.

@coolaj86
Copy link
Author

I appreciate that it prints out that it is building, but I don't disagree about making the output quiet to be consistent with other tools.

I'd like it to have a --verbose flag if you decide to make it quiet by default (or a --quiet or --silent could be added instead)

@coolaj86
Copy link
Author

coolaj86 commented Jun 11, 2020

By digging through the code you referenced I was able to find that if I change the name of the variable from Assets to AdminFS then the name of the file changes from assets_vfsdata.go to adminfs_vfsdata.go:

admin/admin.go:

// +build !dev
//go:generate go run -mod vendor github.com/shurcooL/vfsgen/cmd/vfsgendev -source="github.com/example/my-project/my-module/admin".AdminFS

package admin

admin/admin_dev.go:

// +build dev

package admin

import "net/http"

var AdminFS http.FileSystem = http.Dir("assets")

admin/assets/index.html:

<h1>Hello, Admin!</h1>

Of course, naming it admin.AdminFS stutters a bit, so I think I'll go back to having an assets package with AdminFS and UserFS inside.

@coolaj86
Copy link
Author

Of course, naming it admin.AdminFS stutters a bit, so I think I'll go back to having an assets package with AdminFS and UserFS inside.

I can't have two *_vfsdata.go files in the same directory because there are no prefixes in the variables generated code - they conflict with one another.

@dmitshur
Copy link
Member

That limitation is tracked in issue #23 (also see #44). See that issue for information about workarounds.

dmitshur added a commit that referenced this issue Jun 27, 2020
Writiting to the stdout unconditionally is noisy and inflexible.
The caller is in a better position to decide if anything should
be printed to stdout, and it can already do that. So remove the
uncoditional write from the Generate function.

Don't add anything to vfsgendev, keeping it quiet when everything
is successful. This is consistent with various Go code generators
like stringer, and testing it out over the last few weeks did not
make me feel like something is missing. It's also more consistent
with the philosophy for Unix and Plan 9 tools, where it's nice to
be quiet when all goes as planned.

For #81.
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

No branches or pull requests

2 participants