Support for fonts ttf, eot and woff. problem with the way that URLs a re resolved by Chrome when they're parsed from a dynamically loaded CSS blob

[iLeonelPerea]

here the solution that I implemented for the issue with Chrome http://stackoverflow.com/questions/34133808/webpack-ots-parsing-error-loading-fonts

[coryhouse]

Nice find! Thoughts:

1. The publicPath change should only be required for dev since a separate CSS file is generated in prod, which avoids this issue, correct?

2. A comment next to the publicPath setting referencing this the reason it's useful might be helpful.

3. I'd suggest tweaking the loader settings for eot, ttf, etc to the following.

   {test: /.eot(?v=\d+.\d+.\d+)?$/, loader: "file"},
   {test: /.(woff|woff2)$/, loader: "url?prefix=font/&limit=5000"},
   {test: /.ttf(?v=\d+.\d+.\d+)?$/, loader: "url?limit=10000&mimetype=application/octet-stream"},
   {test: /.svg(?v=\d+.\d+.\d+)?$/, loader: "url?limit=10000&mimetype=image/svg+xml"}

Note the explicit mimetype and use of url loader limits for efficiency.

[iLeonelPerea]

tnks @coryhouse I did the modification to the dev enviroment and add the url-loader dependency.

I think is ready.. 💃

[iLeonelPerea]

@coryhouse fix merge conflicts..

you think is ok now?

[coryhouse]

Thanks for the PR and resolving the merge conflicts! 👍

[coryhouse]

@iLeonelPerea Do you have a simple example we can use to reproduce this?

We may need to change the way we implemented this fix to resolve #205

[kwelch]

I thought for was dynamic, if you are already running you could be on 3002. Wouldn't there be conflicts with this? May want to consider using process.env.port to cover that scenario.

[coryhouse]

Excellent point @kwelch. There's a bug open right now related to this: #181

[kwelch]

I know how to reproduce this. It because an error with bootstrap and using glyphicon. I never attempted to fix since it only affected local dev environment. Basically, with public path reverted and bootstrap in place it cannot find the font to resolve the image.

This PR does properly fix the issue, but it is causing a few others.

I have a couple ideas, I will give them a try and report back.

[kwelch]

So... I don't want to throw in the towel, but these really don't play nice together.

I tried a few different things but still have not had any luck to get both glyphicons and external access (#205).

• Messed around with the ejs template, but publicPath comes from webpack config and actual port declaration takes place in srcServer.js when invoking browserSync. On top of that browserSync is incrementing causing (npm start wants bundle.js on port 3000, while website started on first free port #181)
• Switching to from url to file had no bearing
• Attempting loading webpack from the less file hoping it would bypass fonts based on this thread (Trouble getting bootstrap glyphicons to work webpack/webpack#597)

Those are my notes, hopefully someone has an idea I have not already exhausted.

Other things to consider:

• Bootstrap 4.0 is in alpha, and it officially drops glyphicon support (http://v4-alpha.getbootstrap.com/migration/)
• Slingshot currently does not implement bootstrap
• This issue only affects dev server, I am running a project that is affected by this missing font issue and once built/deployed glyphicons work fine

[kwelch]

This looks promising.

webpack-contrib/style-loader#96 (comment)

It is late will try again tomorrow.

[coryhouse]

@kwelch Thanks for all the digging on this! A tricky one indeed. And yes, that last idea looks promising - it would be nice to avoid the public path complexity altogether.

[kwelch]

Agreed, the true fix would be for the loaders to support relative path.

I am not a huge fan of the hacky way mentioned in the bug thread, and first attempt last night was fruitless.

[kwelch]

Submitted. PR in this using the entry method from the style-loader thread