Command assetfs
generates http.FileSystem implementation compiling assets
inside go binary as byte slices. Generated file exposes function AssetDir()
which usage is similar to http.Dir() usage.
assetfs can generate 2 files: one for production usage, where assets should be
compiled inside binary, and one for development usage, where AssetDir() is
aliases to http.Dir() and files are served from disk. As both files exposes
function with the same name, they're differentiated with build tags.
Usage: assetfs [flags] assetsDir ...
-dev string
path to write development stub
-devtag string
build tag to assign to development stub (default "dev")
-name string
package name
-out string
path to write generated content
-tag string
build tag to use for main generated file
This program is mainly intended to be used with go generate
as follows:
Consider your repository has static
subdirectory which is normally exposed as
http.Dir("static")
. Create file static.go
with the following content:
package mypackage
//go:generate assetfs static
Once you run go generate
, it will produce two extra files:
static_assetfs.go
and static_assetfs-dev.go
. Both expose AssetDir()
function, the latter has this function aliased to http.Dir()
and has dev
build tag set, so it can be used during development when you expect to see
changes in static files as you refresh page. Next thing to do would be to
replace usage of http.Dir("static")
with AssetDir("static")
in your code.
assetfs
main intention is to include small static assets inside compiled
Go binary, so that resulting program has less file dependencies. As all
included files are stored as byte slices, they affect both binary size and
runtime memory consumption, so you should avoid including large files.
Currently the only artificial limit built in is for a single file size (10
MiB).