Client UI cannot be built on Windows

[NightJar]

While this doesn't matter for many folks, I feel it instantly precludes any community member from contributing, which is a reasonably troubling concern.

The majority of the UI builds just fine, but the webpack pipeline does not complete and ends up rendering errors to the output. This happens at the font stage.

I am using Windows 10, and the shell seems inconsequential (first attempted with git-bash, then with the 'windows default' of cmd).

In CMD there is no concept of inlining environment variables:

This is not an issue in git-bash, if one does not attempt to run yarn dev (and friends) as it jumps to this cmd environment internally it seems. Running node_modules/.bin/webpack --progress does successfully run (but not complete). This work around is OK, and not what this issue is about. I am simply being thorough in my report as so people don't confuse the issue (or maybe it's pertinent to debugging).

Since webpack config contains (ENV !== 'production') ? 'source-map' : '', we'll just omit the env var, and make the call adjustment as above: node_modules\.bin\webpack --progress (in CMD, note backslash not forward slash).

Which results in:

        ERROR in ./client/src/font/fonts/silverstripe.eot
        Module parse failed: ..client\src\font\fonts\silverstripe.eot Unexpected character '�' (1:0)
        You may need an appropriate loader to handle this file type.
        (Source code omitted for this binary file)
         @ ./~/css-loader?{"sourceMap":true,"minimize":true,"discardComments":true}!./~/postcss-loader/lib?{"sourceMap":true,"plugins":[null]}!./~/resolve-url-loader!./~/sass-loader/lib/loader.js?{"includePaths":[...

(edited for brevity - but there are also a number of these).

This same error is what pops up in the bash shell, so appears more environmental than command syntax issues.

If one pushes through this results in:

Which is clearly invalid CSS, and leaves the CMS looking like assets weren't exposed by composer.

This also affects the pattern library (storybook): #465
Although I could get that running, the interface in the browser was non-functional and also littered with the same error as above (unknown char in font, etc.)

Related PR

• Making the font tests directory seperator agnostic webpack-config#20

[altwohill]

This should be relatively easy to fix by using cross-env as a devDependancy

[NightJar]

Thanks @altwohill it's good to know the environment variable business in the script alias is an easy fix :)
But unfortunately this issue is a bit bigger than that.

Or are you also reporting that you do not hit fatal errors mid-build (in font files) on windows at the current master HEAD?

[maxime-rainville]

I had a go at fixing this and I think I found the problem. Our webpack rule for handling font file looks like this:

{
    test: /fonts\/([\w_-]+)\.(woff|eot|ttf|svg)$/,
    loader: 'file-loader',
    options: { name: 'fonts/[name].[ext]' }
}

If you tweak the test regex to expect a Windows directory separator (/fonts\\([\w_-]+)\.(woff|eot|ttf|svg)$/), the build process seems to complete normally.

[NightJar]

Neat, I'll give it a go.
Which file am I finding this in?

[maxime-rainville]

@NightJar To debug this, I hacked away into the webpack.config.js. If you replace the last line of that file with this you should be able to get it working on Windows and *nix:

const myTweakedconfig = (process.env.WEBPACK_CHILD)
  ? config.find((entry) => entry.name === process.env.WEBPACK_CHILD)
  : module.exports = config;

myTweakedconfig[2].module.rules[3].test = /fonts[\///]([\w_-]+)\.(woff|eot|ttf|svg)$/;
console.dir(myTweakedconfig[2].module.rules[3])

module.exports = myTweakedconfig

Obviously this is some pretty dodgy stuff. I'll have a look at a better way of fixing this.

[NightJar]

Thanks @maxime-rainville. So what you're saying here is that this should actually be patched in the webpack config directly?

[maxime-rainville]

@NightJar Yes that looks like the best place to put it. Feel free to do a PR for it if you want. Otherwise, I'll do it when I've got a spare 5 min somewhere.

[NightJar]

Hi team, thanks for the work on this! I've tested and it seems to work it has not solved my issue :(
Also I'd like to point out that this issue (being on silverstripe/admin) is not closed until the following line is also updated to access the dependency change:

silverstripe-admin/package.json

Line 89 in 1e4bd77

"@silverstripe/webpack-config": "^0.8.0",

[robbieaverill]

Looks like the change was released in 0.8.1 - that constraint will allow you to install that - are you having problems with it?

[NightJar]

Yes it was released in silverstripe/webpack-config 0.8.1 - but this issue is open on silverstripe/admin, not silverstripe/webpack-config
And unfortunately yes, after updating the package.json to pull the change, the issue persists - same as reported above.

[NightJar]

Have opened a more relevant issue at silverstripe/webpack-config#21
But the fact remains that this issue is not closed, so I should like it to be reopened please (although it amounts to little more than updating the package.json now).

[robbieaverill]

What would you like the package.json updated to? I don't see anything wrong with it, but I'm happy to reopen the issue for you until it's resolved

[NightJar]

It still seemed to pull the unfixed webpack dependency for me - 0.8.0 rather than 0.8.1 - although perhaps I should check I wasn't having a daft moment as reinspecting the constraint it seems it should be fine with the caret.
The build errors are still existing, and it isn't entirely clear whether it's an issue with the webpack config as previously assumed, or this module and it's treatment of the fonts (since webpack config doesn't contain fonts, but is rather heavily tied to this module).

@altwohill 's suggestion would also be nice - but perhaps that warrants wider discussion about whether or not it belongs here or further up in webpack config also - would it work like that?

---

Yeah, trusty ol' rm -rf node_modules saw yarn install the correct version. So that at least is fine :) But still as the issue technically isn't solved... Thanks.

[unclecheese]

I'm not sure there's anything actionable, here. The latest webpack-config release fixes the issue. The version constraints in the package.json afford that version to be installed. It's a single yarn upgrade command to get it. Because this only affects the developer experience, I don't see value in issuing PRs across six modules for yarn.lock updates just to save developers the trouble of running yarn upgrade. Even if we did do PRs, developers would still have to run yarn install to get the new version.

Does that make sense, @NightJar or have I misrepresented your concern?

[NightJar]

The latest webpack-config release fixes the issue.

How did you test this @unclecheese ?

[NightJar]

hahahaha, I can't believe I didn't pick up the slashes added in the fix PR were the wrong way around xD 😓
Sorry for half arsing the check team (and then getting confused as to while it still failed), but @altwohill has come to the rescue :D

silverstripe/webpack-config#24

[maxime-rainville]

@NightJar Awesome! Are you OK if I close this one?

[NightJar]

Is it OK if I test first? :>

[maxime-rainville]

@NightJar Sure go for it.