Skip to content
This repository has been archived by the owner on Mar 17, 2021. It is now read-only.

[v1.0.0] File paths in url() broken (css-loader) #181

Closed
pastelsky opened this issue Jul 26, 2017 · 13 comments · Fixed by #212
Closed

[v1.0.0] File paths in url() broken (css-loader) #181

pastelsky opened this issue Jul 26, 2017 · 13 comments · Fixed by #212

Comments

@pastelsky
Copy link

pastelsky commented Jul 26, 2017

I upgraded to file-loader@1 and this is how @font-face definitions are being rendered -

@font-face {
  font-family: Mrs Eaves XL Serif;
  font-style: normal;
   /* Font file paths are broken */
  src: url([object object]) format("woff2"), 
    url([object object]) format("woff"), 
    url([object object]) format("truetype")
}

The font paths are rendered just fine if I downgrade to v0.11.2

My loader config looks like -

      {
        test: /\.(woff|woff2|ttf)/,
        loader: 'file-loader',
        query: {
          context: path.join(paths.source, 'assets/fonts'),
          name: path.join('..','fonts/[path][name].[hash:5].[ext]'),
        },
      },

This might be happening for outside url() too, but don't have any use cases to test in my current project.

Versions

webpack v3.4.1
node v8.1.2
file-loader v1.0.0

@jasonfah
Copy link

Also having this issue after upgrading while using url-loader (which I believe uses file-loader).

node v6.11.0
webpack 3.4.1
file-loader v1.0.0
url-loader v0.5.9

Windows 10 x64

{
      test: /\.(woff|woff2|eot|ttf|svg)$/,
      loader: 'url-loader',
      options: {
        limit: 10240,
        outputPath: './fonts/',
        name: '[name].[ext]?[hash]',
      }
 }

@delch
Copy link

delch commented Jul 26, 2017

Have a same problem.

node v8.1.4
webpack 3.4.1
file-loader 1.0.0

os x Sierra

      loader: 'file',
      options: {
        name: '[name].[hash:base64:6].[ext]'
      }

@Jessidhia
Copy link

I think this will require an update to css-loader...

css-loader is rewriting url('./file') to use require('file'), but file-loader@1's output is not compatible with require.

@Jessidhia
Copy link

Yep, this is incompatible with the current css-loader.

https://github.com/webpack-contrib/css-loader/blob/v0.28.4/lib/loader.js#L94-L102

It needs to be converted to write hoisted imports.

@stomvi
Copy link

stomvi commented Jul 27, 2017

Same here. file-loader v1.0.0 also breaks the png files loaded when trying to get through the tutorial of the Webpack new guides on page:
https://webpack.js.org/guides/asset-management/

node 8.2.1
webpack 3.4.1
file-loader 1.0.0

OSX Sierra

@joshwiens
Copy link
Member

joshwiens commented Jul 27, 2017

As @Kovensky said, we will have to fix this in css-loader which hasn't been upgraded given it's been rewritten, hence the disconnect.

In the mean time & in the spirit of not making everyone's lives more difficult, i have updated the tags in npm while we sort this out.

'dist-tags': { latest: '0.11.2', beta: '1.0.0-rc.0' }

Please keep in mind that file-loader@1.0.0 was not unpublished, it's just not latest. If you are explicitly targeting 1.0.0 roll that back to 0.11.2. If you are feeling adventurous, use 1.0.0-rc.0.

@Jetsly
Copy link

Jetsly commented Jul 27, 2017

when i change index.js,it ok

 -return `export default ${publicPath};`
 +return `module.exports = ${publicPath};`

@michael-ciniawsky michael-ciniawsky changed the title File paths in url() broken in v1 [v1.0.0] File paths in url() broken (css-loader) Jul 28, 2017
@michael-ciniawsky
Copy link
Member

michael-ciniawsky commented Jul 28, 2017

We could either

  1. add a 'harmony' mode to css-loader options.url to replace
    url('./file.png') =>url('require(./21543.png).default') when set
  2. or inspect package.json in css-loader for file-loader >= v1.0.0 and do the same then :)
  3. revert to CJS for now (:-1:)

@alexander-akait
Copy link
Member

alexander-akait commented Jul 28, 2017

@michael-ciniawsky

  1. We will have many problems when people just forget to add this option.
  2. Sound good.
  3. 👎

@joshwiens
Copy link
Member

We could also simply wait to hear back from Tobias on the state of the style loaders chain / changes & either add defaults to css-loader or wait for css-loader/new-loader.

There is really nothing in file-loader 1.0.0 that's earth shattering feature or fix wide. It's just defaults & style updates.

@jquense
Copy link

jquense commented Aug 28, 2017

can we please revert this change? There doesn't seem to be an value to use es6 imports here, the file on the other end isn't JS its never gonna benefit from treeshaking or any other thing you might use the esm syntax for. On the other hand its subtly breaking for everyone using file-loader in the most popular way (e.g. to chain against css-loader for loading css assets)

I'm sorry if I sound a bit annoyed I just spent 4 hourts trying to figure out why my build was broken

@azeemmirza
Copy link

Revert file-loader to v0.11.2. Works fine.

@joshwiens
Copy link
Member

@jquense - Not entirely sure how this ended up back on dist-tags: latest but file-loader@1.1.4 removes the es6 imports until we can address the actual issue ( css-loader ) which isn't going to happen until after e.t.w.p is retired & becomes part of Webpack.

In short, this isn't going to change again until css-loader/new-loader replaces the existing & Webpack eats e.t.w.p. which should simplify the style sheets loader chain significantly.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.