1

I have this case, working fine on Mac... but when I cloned the repo on a Windows computer the build generates different results (paths) and it's not working.

All routes are relative to the build path:

fonts/abc.ttf

ttf file existing here

styles/styles.less

@font-face {
  font-family: 'abc';
  src: url(../fonts/abc.ttf);
}

examples/example.ts

import '../styles/styles.less';

webpack.config

{
  test: /\.(css|scss|sass|less)$/,
  use: ExtractTextPlugin.extract({
    use: [
      {
        loader: 'typings-for-css-modules-loader',
        options: {
          modules: true,
          importLoaders: 1,
          namedExport: true,
          camelCase: true,
          sourceMap: true,
          localIdentName: '[local]',
        },
      },
      {
        loader: 'postcss-loader',
        options: { plugins: () => [autoprefixer('ie >= 9')] },
      },
    ],
  }),
},
{
  test: /\.(ttf|otf|eot|svg|woff(2)?)$/,
  exclude: /node_modules/,
  use: [{
    loader: 'file-loader',
    options: {
      name: '[name].[ext]',
      useRelativePath: true,
      outputPath: 'fonts',
    },
  }],
},

In the mac environment, the output is correct:

  • the font is placed in fonts/abc.ttf
  • the css file loads it properly with url(../fonts/abc.ttf)

In windows however:

  • the font is placed in fonts/fonts/abc.ttf
  • the css file tries to load it with url(fonts/fonts/abc.ttf) (giving that the css file is placed in /examples/example.css the resulting url would be /examples/fonts/fonts/abc.ttf so it's a 404

So basically 2 questions:

  • why the url is duplicated (as fonts/fonts)?
  • why the css is not able to detect properly the relative url and add the .. to its path?

And well, above all, why the results are not the same in win/mac?

danikaze
  • 1,550
  • 2
  • 16
  • 34
  • This is a shot in the dark, but I think this is related to the webpack setting `node : { __dirname : "mock" }` which is the default and makes `__dirname` result in `/`. I think there are instances this will not be interpreted the same on mac an windows (most likely in how some loader or plugin handles it). I would try with `{ node: { __dirname: false }}` instead. Also having ran into quirks with outputPath before, I would give up on changing the `outputPath` when possible. You can use `name: 'fonts/[name].[ext]',` and there'll be less side effects. (Sorry, no real answer here!) – ippi May 07 '18 at 15:49
  • @ippi got the error. Was a bug? of file-loader. In mac 1.1.6 version was installed, in Win 1.1.11... even if the yarn.lock resolved both to the same file (why?) but anyways, fixing the version fixed the problem. Thanks for trying to help – danikaze May 13 '18 at 04:50

1 Answers1

0

The error was due to different versions being installed (1.1.6 vs 1.1.11) It might be that the latests introduce a bug, but installing the same version fixed the problem.

PS: Different versions was caused due to cleaning yarn.lock for different reasons.

danikaze
  • 1,550
  • 2
  • 16
  • 34