Buffalo fails to start/build/test on Windows

[marpaia]

Running the buffalo dev command on Windows on a fresh project returns the following cryptic error:

> buffalo dev
Buffalo version 0.7.1

There was a problem starting the dev server: Unknown

The buffalo build command also fails, with a more potentially useful error:

> buffalo build
Buffalo version 0.7.1

--> running ./node_modules/webpack/bin/webpack.js
--> cleaning up build
--> cleaning up buffalo_build_main.go
Error: fork/exec ./node_modules/webpack/bin/webpack.js: %1 is not a valid Win32 application.

Also, when running buffalo test:

> buffalo test
Buffalo version 0.7.1

go test github.com/marpaia/website github.com/marpaia/website/actions github.com/marpaia/website/grifts github.com/marpaia/website/models
buffalo_build_main.go:11:2: cannot find package "github.com/marpaia/website/a" in any of:
        C:\Go\src\github.com\marpaia\website\a (from $GOROOT)
        C:\Users\marpaia\go\src\github.com\marpaia\website\a (from $GOPATH)

buffalo_build_main.go contains:

import (
        "fmt"
        "io/ioutil"
        "log"
        "os"
        "path/filepath"

        rice "github.com/GeertJohan/go.rice"
        _ "github.com/marpaia/website/a"
        "github.com/marpaia/website/models"
)

I have an assets subdir and an actions subdir, but no a subdir.

Let me know if I can help debug this if it's unusual behavior.

[bscott]

We have two existing issues regarding this and a PR to help with this.

This error is usually due to node and npm missing on your system. Also ensure the npm webpack package installed.

[marpaia]

@bscott I have npm and node installed. Even after installing webpack globally just now via npm install -g webpack (and verifying that the webpack command is in my path), everything still fails with the same errors.

[bscott]

@marpaia I'm looking at the packages, seems there might be some Windows specific issues with the pathing.

Error: fork/exec ./node_modules/webpack/bin/webpack.js: %1 is not a valid Win32 application.

That error catches my eye, I'll loop @markbates and @apaganobeleno to any ideas they might have but I think I feel some new PR's having to be created.

[bscott]

@marpaia Regarding buffalo test, is your $GOPATH setup properly?

[marpaia]

@bscott yeah, my $GOPATH is set to ~/go. With that error, the issue is that buffalo_build_main.go is trying to import a package (github.com/marpaia/website/a) which doesn't exist. In this example, github.com/marpaia/website is the path where I have buffalo new'd.

[markbates]

So there's two things going on here. Looks like buffalo build didn't clean up after itself properly after the failure, that's why you're seeing files like buffalo_build_main.go, which you should get removed after build, same thing with the a package.

There's also the the web pack path issue. @marpaia can confirm if you change ./node_modules/webpack/bin/webpack.js to the "proper" windows path that it works? Using a local install of web pack was a recent change to prevent issues with installing it globally, so if we can find the path structure that works for all platforms, that would be great!

Thanks.

[markbates]

I've pushed up a PR #168, hopeful this fixes the web pack issue. I'll need more time to figure out why the build didn't clean up properly after itself.

[marpaia]

@markbates awesome! I can confirm that #168 fixes the webpack issue, which allows buffalo build to complete successfully. Thus, it seems like buffalo_build_main.go gets cleaned up properly (so buffalo test also works now).

The only thing that still isn't working on Windows is buffalo dev:

C:\Users\marpaia\go\src\github.com\marpaia\website> buffalo dev
Buffalo version 0.7.1

buffalo: 2017/01/24 08:32:54 === Rebuild on: :start: ===
buffalo: 2017/01/24 08:32:54 === Running: go build -v -i -o tmp/website-build (PID: 8360) ===
github.com/marpaia/website/models
github.com/marpaia/website/actions
github.com/marpaia/website
buffalo: 2017/01/24 08:32:56 === Building Completed (PID: 8360) (Time: 2.3064398s) ===
buffalo: 2017/01/24 08:32:56 === exec: "tmp/website-build": file does not exist
 ===
Hash: 11d5c49d209190c5a776
Version: webpack 1.14.0
Time: 3531ms
                                 Asset     Size  Chunks             Chunk Names
af7ae505a9eed503f8b8e6982036873e.woff2  77.2 kB          [emitted]
  f4769f9bdb7466be65088239c12046d1.eot  20.1 kB          [emitted]
 fa2772327f55d8198301fdb8bcfc8158.woff  23.4 kB          [emitted]
  e18bbf611f2a2e43afc071aa2f4e1512.ttf  45.4 kB          [emitted]
  89889688147bd7575d6327160d64e760.svg   109 kB          [emitted]
  674f50d287a8c48dc19ba404d20fe713.eot   166 kB          [emitted]
448c34a56d699c29117adc64c43affeb.woff2    18 kB          [emitted]
 fee66e712a8a08eef5805a46892932ad.woff    98 kB          [emitted]
  b06871f281fee6b241d60582ae9369b9.ttf   166 kB          [emitted]
  912ec66d7572ff821749319396470bde.svg   444 kB          [emitted]
                        application.js   372 kB       0  [emitted]  main
                       application.css   183 kB       0  [emitted]  main
                       images/logo.svg    66 kB          [emitted]
   [0] multi main 52 bytes {0} [built]
    + 21 hidden modules
Child extract-text-webpack-plugin:
        + 15 hidden modules

Note the following line:

buffalo: 2017/01/24 08:32:56 === exec: "tmp/website-build": file does not exist

Note that ./tmp/website-build DOES exist and it IS a correctly compiled binary, but Windows expects it to be called ./tmp/website-build.exe. Renaming the output binary and executing it runs the webserver properly. Without digging through the code, I'm not sure where the output binary path is created, but adding a .exe should do the trick here.

Thanks for looking into this @markbates! This is a cool project and I liked your GoTime episode :)

[markbates]

Thanks! In the .buffalo.dev.yml file in your project you can change the name of the bin. Can you open an issue for that, so we can track it and fix it for all platforms? Thanks.

[marpaia]

Confirmed that adding .exe to the binary_name in .buffalo.dev.yml compiles and runs the binary properly. It would be cool if buffalo could auto-detect that though and append the .exe implicitly so that the same dev file could be used on OS X, Linux, and Windows without modification. Would you like an issue for that, specifically?

[markbates]

Yes. Please open issue for that. Thanks. Make sure to reference this issue when you do. Thanks.