jkomoros / boardgame

An in-progress framework in golang to easily build boardgame Progressive Web Apps
Apache License 2.0
31 stars 4 forks source link

`boardgame-util golden` and friends #667

Open jkomoros opened 5 years ago

jkomoros commented 5 years ago

Originally captured in #655.

Add bu build golden and bu clean golden

An alias for bu build golden, bu serve --storage=filesystem --clean-up, bu cleanup golden

Basically a mode where we wire up and allow serving goldens

Remove the golden behavior from filesystem

golden.LinkGoldenFolders should be split into a more generic helper library that can be used for golden folder generation as well as server client-files auto-siymlnking

jkomoros commented 5 years ago

Add to TUTORIAL.md in the "writing your own game" section

jkomoros commented 5 years ago

It might be simpler to just have golden take a single game import and wire everything up so that you can save new goldens. boardgame-util golden github.com/jkomoros/boardgame/examples/checkers. That makes the wiring up and cleanup easier to wrap your head around, and in practice you don't want to run multiple games in golden mode anyway.

jkomoros commented 5 years ago

boardgame-util golden DIR where DIR can be a package name or a relative path to a game package.

That command first verifies that the given package is a legal game package (moving golden.verifyPkgPath and making a public part of link package). If it passes, and testdata/golden doesn't yet exist, creates it, and also creates the golden_test.go.

Then runs build golden PKGNAME which basically creates a build/filesystem/PKGNAME that is symlinked to the absolute package directory + testdata/golden. Then calls boardgame-util serve but with an override specific gamename only, and --storage=filesystem. The teardown for boardgame-serve naturally cleans up the golden folder structure.

jkomoros commented 5 years ago

There's a fair bit more behavior to add to the lib/path library. Could want to 1) Take a string and decide if it's a relative path to a game source dir, or a go import, 2) Get an absolute path to the given go library, 3) decide if it's likely to be a game package path (that is, have NewDelegate with right signature), 4) tell if it's a readOnly location or can be modified. 5) Tell if it has other files like a sub-folder structure of a given shape, the existence of files like golden_test.go, etc.

The easiest way to do this is to have a new struct called GameImport that abstracts away all of this knowledge. lib/path then becomes way more powerful, and becomes more like lib/gameimport.

jkomoros commented 5 years ago
jkomoros commented 5 years ago

Filesystem should only store in multiple named folders by game type if there's more than one game manager. (Ideally this behavior can be enabled or disabled). Because with golden, it only runs for one thing at a time, and it's way easier if we can just tell it to store in a single folder, and not have to create all kinds of additional faux folder structure. Actually wait--if given a folder there is a subfolder with the gametype's name it will save in there and look in there first. But if not, will just store in the given folde.r That way there isn't multiple options to pass,.

Golden files should be stored in testdata/golden so as to not conflict with other testdata

jkomoros commented 5 years ago

Consider renaming the tool to boardgame-util create-goldens to make it more clear that it's a very rare tool

jkomoros commented 5 years ago