Issues building in a Microsoft Windows environment

[NightJar]

I am using git bash as provided by git for windows as provided by https://git-scm.com/download/win

When it comes to building the admin client package various errors are expreienced with parsing font files - as described at silverstripe/silverstripe-admin#495 (comment)

At first it was thought to be the font pathing with windows having a backslash (\) path separator, as compared to the POSIX forward slash (/) - however this has been patched in #20 and released as 0.8.1 (where the issue was first exhibited with 0.8.0), and the issue persists.

Also more ideal would be the ability to support other environments via the cross-env dev dependency as suggested by @altwohill at silverstripe/silverstripe-admin#495 (comment) as to reduce the number of work-arounds needed to get script commands running in the first place.

[robbieaverill]

Just testing this out with a bunch of devs on Windows and having lots of problems with standard yarn build commands. Both with NODE_ENV compatibility and eslint client/src "folder not found" problems.

[NightJar]

@robbieaverill see comment from @altwohill as posted above.

If (and only if) the devs are using a bash type shell, the workaround (under the big image with all the PASSes in it) should work, as evidenced in testing
Essentially: manually expand the script alias as defined in the package.json
$ node_modules/.bin/eslint client/src/ && node_modules/.bin/sass-lint -v && node_modules/.bin/jest && NODE_ENV=development node_modules/.bin/webpack -p --bail --progress

If a windows dev does not have a POSIX-ish shell installed (i.e. are using CMD.exe), then I think the only workaround would be to install the cross env module as suggested by Al. Unfortunately I've not tried this, so far as I can remember.

TL;DR even though compilation works now, it's still a very shit experience. But manageable if and only if said person having such an experience doesn't give up through

• little experience with yarn or webpack or npm (knowing how scripts work)
• not big on being a (front-end|javascript) developer, it should "just work":tm: (not wrong)
• bad experiences are too hard lets just use <other solution here> instead. (first experiences are rather lasting)

I.e. being rather ambivalent/apathetic about finding said workaround.