Failed generate does not undo what did succeed.

[chasenyc]

Steps to Reproduce the Problem

If buffalo fails midway through generating a resource it does not undo what it has done in app.go. This is a very minor issue and was easy to resolve by deleting the duplicated resources from app.go. If I wasn't so new to go I'd be attempting to see if I could make a PR to fix this issue.

1. call buffalo g resource users name email bio:nulls.Text with the buffalo executable file not found in $PATH. (execute buffalo without it being in your path folder).
   
2. repeat
3. move buffalo to your path folder
4. run buffalo g resource users name email bio:nulls.Text again

Expected Behavior

I think it would be nice if this was wrapped in some sort of transaction and would undo all steps if it fails midway through.

Info

### Buffalo Version
v0.11.0

### App Information
Pwd=/Users/alexharris/go/src/github.com/chasenyc/coke
Root=/Users/alexharris/go/src/github.com/chasenyc/coke
GoPath=/Users/alexharris/go
Name=coke
Bin=bin/coke
PackagePkg=github.com/chasenyc/coke
ActionsPkg=github.com/chasenyc/coke/actions
ModelsPkg=github.com/chasenyc/coke/models
GriftsPkg=github.com/chasenyc/coke/grifts
VCS=git
WithPop=true
WithDep=false
WithWebpack=true
WithYarn=true
WithDocker=true
WithGrifts=true

### Go Version
go version go1.8.3 darwin/amd64

### Go Env
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/alexharris/go"
GORACE=""
GOROOT="/usr/local/Cellar/go/1.8.3/libexec"
GOTOOLDIR="/usr/local/Cellar/go/1.8.3/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/tr/rznqg4rd7zbbq3qz8hb3wqhc0000gn/T/go-build573612720=/tmp/go-build -gno-record-gcc-switches -fno-common"
CXX="clang++"
CGO_ENABLED="1"
PKG_CONFIG="pkg-config"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"

### Node Version
v9.4.0

### NPM Version
5.6.0

### Yarn Version
1.3.2

### PostgreSQL Version
pg_ctl (PostgreSQL) 10.3

### MySQL Version
mysql  Ver 14.14 Distrib 5.7.21, for osx10.12 (x86_64) using  EditLine wrapper

### SQLite Version
3.16.0 2016-11-04 19:09:39 0e5ffd9123d6d2d2b8f3701e8a73cc98a3a7ff5f

### Dep Version
dep Not Found

### Dep Status
dep Not Found

[stanislas-m]

How about making a copy of the modified files, modify the copy, and remove the original file on success?
So on "rollback", you'll just have to delete the copies.

If I wasn't so new to go I'd be attempting to see if I could make a PR to fix this issue.

That's not a problem, we're here to help! Start something from this idea if you like it, then we'll give you a hand to improve, if necessary. :)

[orderbynull]

I'm interested in fixing this. Is it still relevant? @stanislas-m

[stanislas-m]

Sorry, I didn't see your message @orderbynull. It's still relevant. :)

[owen2345]

The problem persists!

[Jameshudson]

I take it no one fixed this issue? I'd be happy to help.

[markbates]

Go for it.

…

----------- Mark Bates

On Mar 20, 2019, 11:24 AM -0400, James Hudson ***@***.***>, wrote: I take it no one fixed this issue? I'd be happy to help. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[serajam]

Duplicate routes will occur even if generation succeeded after calling same command twice. Maybe it's better to check for identical lines of code while generating?

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[github-actions]

This issue was closed because it has been stalled for 5 days with no activity.