Buffalo v0.14.0-rc.1 Released!
Please read through the notes to see what is new, what has been improved, and most importantly, what might be breaking changes for existing applications.
In addition to what is listed here, it is recommended that you read the CHANGELOG for a complete list of what has changed in v0.14.0-rc.1.
How to Upgrade
Because this is a release candidate version, and not an official release you can not use go get to install this version.
Note: Because this is not an official release you will need to be using a package manager for your application, such as dep, or Go Modules, to use this release.
Pre-built Binaries
The easiest solution is to download one of the pre-built binaries:
https://github.com/gobuffalo/buffalo/releases/tag/v0.14.0-rc.1
From Source
$ go get github.com/gobuffalo/buffalo
$ cd $GOPATH/src/github.com/gobuffalo/buffalo
$ git checkout tags/v0.14.0-rc.1 -b v0.14.0-rc.1
$ make installOnce you have an upgraded binary you can run the following command to attempt to upgrade your application from v0.13.x to v0.14.0-rc.1.
$ buffalo fixNote: While we have done our best to make this update command work well, please understand that it might not get you to a complete upgrade depending on your application and its complexities, but it will get you pretty close.
What’s New
Rewritten Generators
In v0.14.0 all of the generators have been rewritten using https://github.com/gobuffalo/genny.
This work, not only improved the stability of the generators, but lays the ground work, along with the work in plugins, to help achieve the v1.0.0 goal of opening up the generator system to everyone.
In v0.15.0 most of the Buffalo generators will be moved into their own plugins and hooks will be added to allow anybody to override any of the generation steps.
See https://blog.gobuffalo.io/the-road-to-1-0-the-beginnings-34bc5e7603d2 for more information.
Packr v2 Support
Packr v2 is a significantly improved version of Packr. For a full write up, and video overview, see https://blog.gobuffalo.io/packr-v2-0-0-rc-3-introduction-7a5e06a688c5.
Some highlights of Packr v2 are:
- import path resolution — Packr v2 will find all of the boxes your application, and its dependencies, rely on.
- improved disk storage — Packr v2 has a new disk storage that prevents duplicate boxes, and files, from being packed.
- custom storage options — you can now write your own custom storage engines for Packr. For example, you can write a store to pack your files to S3 or a database.
- custom file resolvers — you can write your own custom resolvers to find files packed using custom stores.
New Mod Flag
The buffalo build command now supports a --mod flag that can be used to pass information to the go build -mod flag.
For example, when using Go Modules with a vendor directory you would do go build -mod vendor. When using buffalo build you can pass that same information like this buffalo build --mod=vendor. This is very useful for CI environments.
Plugin Speed Improvements
The buffalo-plugins plugin now has support for cache to speed up load times when searching for plugins. This cache can be disabled using the environment variable BUFFALO_PLUGIN_CACHE=off.
The cache can be managed with a series of cache sub-commands:
commands for managing the plugins cacheUsage:
buffalo-plugins cache [command]Available Commands:
build rebuilds the plugins cache
clean cleans the plugins cache
list displays the contents of the plugin cacheFlags:
-h, --help help for cacheUse "buffalo-plugins cache [command] --help" for more information about a command.
An example of the cache file looks like this:
{
"~/go/bin/buffalo-plugins": {
"check_sum": "bef8cac531e01a2006a40a0fd934ceade1749683cdce14d3d8c83b95609a17a9",
"commands": [
{
"buffalo_command": "generate",
"description": "generates a new buffalo plugin",
"name": "plugin",
"use_command": "plugin"
},
{
"buffalo_command": "root",
"description": "tools for working with buffalo plugins",
"name": "plugins",
"use_command": "plugins"
},
{
"buffalo_command": "events",
"description": "listens to github.com/gobuffalo/events",
"listen_for": "buffalo:setup:.+",
"name": "listen",
"use_command": "listen"
}
]
},
"~/go/bin/buffalo-pop": {
"check_sum": "8de4fed7e82223dacfe3e58689c14581e87853a8575aa9765e1c7f08621e3ba0",
"commands": [
{
"aliases": [
"db"
],
"buffalo_command": "root",
"description": "[DEPRECATED] please use `buffalo pop` instead.",
"name": "db",
"use_command": ""
},
{
"aliases": [
"db"
],
"buffalo_command": "root",
"description": "A tasty treat for all your database needs",
"name": "pop",
"use_command": ""
},
{
"aliases": [
"m"
],
"buffalo_command": "destroy",
"description": "Destroys model files.",
"name": "model",
"use_command": ""
}
]
}
}As part of the speed improvement the API for listening for events has been improved to offer a listen_for key that will tell Buffalo to only send events to plugins that match the regex pattern provided. This is a change from previously, where all plugins were called for all events.
var Available = plugcmds.NewAvailable()func init() {
Available.ListenFor("buffalo:setup:.+", Listen)
Available.Mount(rootCmd)
}
Plugin Configuration Support
Buffalo now has a config directory to help, not just Buffalo, but plugins as well manage configuration information.
The config/buffalo-plugins.toml file controls how Buffalo will see and manage plugins.
An example file for an app created with buffalo new coke --db-type=sqlite3would look like this:
[[plugin]]
binary = "buffalo-plugins"
go_get = "github.com/gobuffalo/buffalo-plugins"
tags = ["sqlite"][[plugin]]
binary = "buffalo-pop"
go_get = "github.com/gobuffalo/buffalo-pop"
tags = ["sqlite"]
With this file Buffalo can help manage your plugins for you.
Usage:
buffalo-plugins [command]Available Commands:
available a list of available buffalo plugins
cache commands for managing the plugins cache
help Help about any command
listen listens to github.com/gobuffalo/events
plugin generates a new buffalo plugin
plugins tools for working with buffalo plugins
version current version of buffalo-pluginsFlags:
-h, --help help for buffalo-pluginsUse "buffalo-plugins [command] --help" for more information about a command.
Application MetaData
Buffalo now supports a config/buffalo-app.toml file which drives how the https://godoc.org/github.com/gobuffalo/meta package behaves.
An example of this file for a newly generated application looks like this:
name = "coke"
bin = "bin/coke"
vcs = "git"
with_pop = true
with_sqlite = false
with_dep = false
with_webpack = true
with_nodejs = true
with_yarn = true
with_docker = false
with_grifts = false
as_web = true
as_api = falseWith this file application developers can tell Buffalo, and plugins, what their application “looks like”.
As an example, if as_api was set to true then buffalo generate resourcewould not generate template files by default.
Better CI Testing
While not a “feature” of Buffalo, during the development cycle for v0.14.0we revamped our CI testing to better test Windows support as well as Go versions that we support.
The current matrix looks like this:
- Windows and Unix — Go 1.9.x
- Windows and Unix — Go 1.10.x
- Windows and Unix — Go 1.11.x
GO111MODULES=off - Windows and Unix — Go 1.11.x
GO111MODULES=on - Integration tests via Docker
These changes apply to almost all projects in the github.com/gobuffaloorganization.
Improved Asset Caching
In v0.14.0 http caching support for assets served with app.ServeFiles has been added. Buffalo now adds ETag and Cache-Control headers to assets being served.
ETag contains the last modified date for the asset, while Cache-Control by default, will contain: max-age=31536000, where 31536000 can be changed by setting ASSETS_MAX_AGE environment variable to the value of your preference.
Clean Assets Flag
The buffalo build command has a new flag, --clean-assets. When called with this flag the buffalo build command will delete the public/assets folder before calling Webpack to compile the assets. This helps to ensure that only the freshly compiled assets are in the binary.
Default Error Handler Support
In v0.13.0 we introduced the buffalo#App.ErrorMiddleware field. While the idea behind providing a custom “catch-all” for all errors is good, the execution was flawed and it never quite worked correctly.
In v0.14.0 we have removed the buffalo#App.ErrorMiddleware field and instead have added a function to the buffalo#ErrorHandlers type, Default.
This new Default function allows you set a custom ErrorHandler that will be used if no other ErrorHandler has been mapped to the error status code.
app.ErrorHandlers.Default(func(code int, err error, c Context) error {
res := c.Response()
res.WriteHeader(418)
res.Write([]byte("i'm a teapot"))
return nil
})Breaking Changes
Removed Fields
buffalo#App.ErrorMiddlewarehas been replaced withbuffalo#App.ErrorHandlers.Default.
Removed Packages
github.com/gobuffalo/buffalo/middlewaregithub.com/gobuffalo/buffalo/generatorsgithub.com/gobuffalo/buffalo/buffalo/cmd/build
In addition to what is listed here, it is recommended that you read the CHANGELOG for a complete list of what has changed in v0.14.0-rc.1.
Are you a company looking for Buffalo or Go training? The Gopher Guides want to help. We offer a variety of options, including In Person Training, Instructor Led Online Workshops, Consulting, and Support Contracts, and our self paced Online Video Learning.
Get your first 3 months of www.gopherguides.tv for 33% off! This offer is only good for a limited time, and a limited number, so act fast!
