Support modules

[jkomoros]

Dependency on #659, because need to switch to go 1.11

[jkomoros]

The hardest part about this is that the boardgame package will be in a cached location, and it's also possible that if I were to modify the cahced location (for example to update node_modules) then the checksum would change and it would no longer validate.

boardgame-util has to handle all of the following cases well:

1. Operation within the github.com/jkomoros/boardgame repo
2. Operation when github.com/jkomoros/boardgame is explicitly checked out on disk
3. Operation when you don't have github.com/jkomoros/boardgame explicitly checked out on disk

The only thing we need to provide that's not in the repo is node_modules. Worst case scenario can create a cache directory in your repo (do we need to add something to .gitignore?... shouldn't boardgame-util stub output a .gitignore?) where we have a node_modules that we link back to

Update tutorial.md to not say that you have to run go get github.com/jkomoros/boardgame . But if we do that then we need a go get for each of those go packages to ensure they exist on disk ... although I guess if the build api has already run then they already will have been downloaded. Test that this works well even for totally new checkouts.

Update the tutorial.md given that now go get github.com/jkomoros/boardgame won't do much useful.

Get rid of vendor/ directory

[jkomoros]

Another (probably bad) option is to just check in node_modules...

[jkomoros]

• [x] Searching for config shouldn't care if it falls out of gopath
• [x] AbsolutePkgPath doesn't work for server/static because that's not a package with go files, so AbsolutePkgPath will have to be used and then add server, static to get the underlying folder
• [x] Create AbsoluteServerStaticPath() (string, error), that uses GoAbsolutePkgPath() and combines with static/server.
• [x] Use AbsoluteServerStaticPath() in static.build
• [x] Figure out where to stash generic caches in a safe place (os.UserCacheDir)
• [x] finish commit on mac pro
• [x] get rid of build.Static.forceNode, now that we always run npm up
• [x] On first download of node_modules print a message because it will take awhile, on second run say "this should be faster"
• [x] Add ResetCaches() and also add a command for it
• [x] Add an --override-config={default,sample,minimal} that ignores the config on disk and basically juse uses the given config init TYPE provided instead. This is then useful for the first run, with no config necessary.
• [x] Figure out what -mod flag does (can it be used to turn off network?)
• [x] go list DOES download packages
• [x] Enable module support via env flag on both computers
• [x] Get rid of the checkouts in ~/Code and use the ones in $GOPATH
• [x] GoAbsolutePkgPath should check first for the path existing in $GOPATH and use that if it does; cover in its documentation that that's so that you don't have to go out via VCS if you're offline
• [x] Static build should call go get on things where go list doesn't work . (Should that be in a verify step in config lib, if we have others there?)
• [x] Check what go get does if you're in $GOPATH and already ahve the package there; see what it does if you're not sitting in $GOPATH but have a package there
• [x] Create the test-games repo as a tester item (just use config init and stub example)
• [x] update error messages around GoAbsPkgPath usage to be more clear
• [x] Make all of this stuff work, but then go back to just being in GOPATH and having that be primary because modules kind of suck right now since things like godoc and others aren't updated to work with them correctly
• [x] Should we stop relativizing game dir paths in build.Static()? It used to be they were nearby, and possibly checked in. But now they could be anywhere. I guess there's no harm in them being relative...
• [x] tutorial should say you have to use --unsafe-perm to install polymer
• [x] Create a public test-games repo with a single test-games just to test how it works with public repos
• [x] for build.Static() prod = true, have node_modules be literally in the created dir
• [x] If go list GAMEIMPORT doesn't exist, go get it, to ensure the packages are cached (Doesn't go list actually download it if it doesn't exist locally yet?)
• [x] node_modules should be looked for in os.UserCacheDir joined with com.github.jkomoros.boardgame and linked from there, not in the main package. Print to console when creating it about where it's created. build.Static() needs to explicitly link it
• [x] Figure out why override-starter-config=default doesn't work with boardgame-util serve
• [ ] Wait until after 1.12 is released and modules are enabled by default to do the rest of these, because until it's on by default it's annoying all of the random bugs and gaps in tooling when using them
• [ ] One downside is that even two repos on the same computer have to be synchronized by pushing and then pulling separately (maybe it can first look for them in $GOPATH and then look for them elsewhere (although if you have network the most up to date is probably most useful) (if they're in minimizeNetwork mode--which would be yet another static build flag, making #671 an even better idea). There are some patterns (described in points below this) where you use replace directives in go.mod to point to local copies
• [ ] Have logic in relativize paths (or a wrapper) for use in build/static that if the path we're pointing to is in the $GOPATH/pkg/mod path, do an absolute not relative path, because relative paths are only useful if the items are relative to one another very directly (either no modules and in $GOPATH, or modules with a replace directive). If we end up doing an absolute path, emit a file with #nocommit (and document that behavior) to help people ensure they don't accidentally check that in
• [ ] Verify what go list does for a module that has a replace to a local folder. Presumably it will give the local location, which would make the above bullet work correctly as long as we look for $GOPATH/pkg/mod in the path
• [ ] Update tutorial to say you should use overridestarterconfig to start
• [ ] the games repo doesn't work due to credentials: github.com /golang/go/issues/26134
• [ ] First run instruction is go install github.com/jkomoros/boardgame/boardgame-util (which fetches github.com/jkomoros/boardgame and caches it), then run boardgame-util serve --override-starter-config=sample which can be run from anywhere. then the next step in the tutorial is to clone the actual boardgame repo in order for the reader to look at it more closely and poke at it
• [ ] Make sure that npm up handles no network fine
• [ ] https://github.com/thepudds/go-module-knobs/blob/master/README.md
• [ ] See how to disable network effects as much as possible https://github.com/golang/go/wiki/Modules#what-is-the-status-of-module-support-in-ides-editors-and-standard-tools-like-goimports-gorename-etc
• [ ] build.Static in Prod mode shoiuldn't use the cached node_modules, should use a fresh literal copy)
• [ ] Delete the old games, boardgame checkout in go path
• [x] always run npm up. If it fails but node_modules already exists then warn but keep going
• [ ] Check out new games and boardgame in ~/Code on MBP
• [ ] Update tutorial.md to say how to install boardgame-util and get started given that go get of the module won't do very much

[jkomoros]

Commit 76839d8c31a9902891cbe4d02cd1ac0018cdf70e was also related to this issue