webpack / loader-utils Goto Github PK

loaderUtils.urlToRequest('path/to/module.js')  // './path/to/module.js' 

loaderUtils.urlToRequest('~path/to/module.js') // 'path/to/module.js' , 

loaderUtils.urlToRequest('/path/to/module.js', '~') // 'path/to/module.js', 

ok, I got the idea.

loaderUtils.urlToRequest('path/to/module.js', ~) // ./path/to/module.js'  what ???

now i am confused. is it supposed to behavior like this ?

I have a specific need to use CRC32 hashes for file-loader to align with our backend implementation. It appears that it's not supported by crypto-js that you use in your interpolateName function. Not sure if this is something you would consider implementing (with the crc-hash library on npm) or if I should feature request over at crypto-js?

Maybe there are other ways to solve this? Could the customInterpolateName option be used for this purpose?

Is there a standard way to represent arrays in a loader query?

utils.parseQuery('?a=1&a=2&a=3')
// -> { a: "3" }

The [emoji] implementation is not deterministic. 🐱

We need to get rid of the Math.random and the splice from the emoji list. Instead [emoji] should be a emoji hash of the content.

This is likely a great contribution opportunity for anyone interested!

Hi! I noticed that installing loader-utils brings a lot of cruft with it, most of it from the json5 dependency. That issue was identified and fixed, but loader-utils is depending on ^0.4.0. I did a quick check, and it seems like updating json5 to the latest version (and big.js for that matter) doesn't seem to break anything and the tests still pass.

Any chance you could update these dependencies and publish an updated version of this on npm? Happy to submit a pull request if that makes it easier.

Hi, I wanted to introduce CSS Module into an AngularJS project, however the way the loader parses class names won't work with angular's expressions. If file name of the imported CSS file contains a dash, the following configuration of the loader will throw cause Angular to throw the browser:

'css-loader?modules&localIdentName=[name]__[local]__[hash:base64:5]',

It will throw because dashes are not allowed in the ngClass brace expressions in Angular. Would there be a way to either provide a method to strip any non alphanumerical characters from name or wrap the name in single quotes?

Hi, thank you for the useful tool.

So, I understand that the getOptions is provided instead of the getLoaderConfig and parseQuery, in new version.
But I hope that the parseQuery is exported by new version also because that is useful for parsing other query strings e.g. context.resourceQuery.

loader-utils still has the parseQuery, and we can import it by

require(path.resolve(path.dirname(require.resolve('loader-utils')), 'parseQuery.js'))

Of course I know this is not good way.
I hope that the loader-utils exports the parseQuery and supports it.

I have a loader that contains the call .getRemainingRequest(this). In my tests, I have loader.call({}, 'some string') which throws the following error due to the lack of loaderContext:

TypeError: Cannot call method 'slice' of undefined
      at Object.exports.getRemainingRequest (/project/node_modules/loader-utils/index.js:46:38)
      ...

Like parseQuery, perhaps these methods should not assume a context will always be provided?

Currently if no loader options are set, getOptions(this) returns null by default, which requires a fallback to avoid breaking further options.x references within the loader.

const options = loaderUtils.getOptions(this)

Is that intended for some reason or would it be possible to return an empty {}by default instead ?

We're seeing a failure to resolve a module via css-loader since 0.2.17 was released. If we include 0.2.16 as a devDependency then we don't see the problem.

I know I should build a small test case that displays the problem but we have a large webpack build. I'd rather get the word out if others are having problems.

Hi there,

I am working on a loader that needs to compile an array of loaders and options into one string.

I've noticed that vue-loader authors have implemented similar functionality in their code base: vue-loader/lib/loader.js.

I am wondering if this is something that could be part of loader-utils since it could be a helpful function for other loaders as well?

I can create a PR with tests if there will be a need for this helper function.

I placed this issue webpack-contrib/sass-loader#155 on sass-loader but maybe it is more appropriate there. I'm trying to figure out how to stringify an object to be parsed by loader-utils. I tried using json5 directly with no luck, and tried encodeURIComponent on the stringified object but when it is parsed it is a string not an object. Is there some way to accomplish this?

let functions = {
  'image-url($filename)': function(filename) {
    var imageUrl = process.env.NODE_ENV === 'development' ?
      '' :
      '';//enter CDN path here
    var fileName = filename.getValue();

    var imagePath = 'url("' + imageUrl + '/' + fileName + '")';
    /*eslint-disable */
    return new sass.types.String(imagePath);
    /*eslint-enable */
  }
}

`sass-loader?functions=${somehowStringify(functions))}`

Update: got passing object as query param to work, but still found no way to do this programmatically by stringifying a series of objects

Issue was pilot error. You can delete this.

I use source-map-loader and it fails to load sourcemaps with absolute POSIX paths. It is turned out that this function is invoked at the end and it cares only win absolute paths, POSIX are treated as relative.

Current behavior
request

'!!/path-to-project/node_modules/css-loader/index.js
!/path-to-project/node_modules/less-loader/index.js?{"modifyVars":{"@icon-url":"\'../../../src/fonts/iconfont\'"}}
!/path-to-project/node_modules/any/lib/index.less'

loaderContext.context

'/path-to-project/src'

output

'!!./../../../css-loader/index.js
!./../../../less-loader/index.js?{"modifyVars":{"@icon-url":"\'../src/assets/fonts/iconfont\'"}}
!./index.less'

@icon-url is changed

Expected behavior

'!!./../../../css-loader/index.js
!./../../../less-loader/index.js?{"modifyVars":{"@icon-url":"\'../../../src/assets/fonts/iconfont\'"}}
!./index.less'

webpack 1.14.0
Node.js 7.4.0
mac os 10.12.3

I have send a PR

Due to the inconsistent usage of decodeURIComponent, certain results are unobtainable with parseQuery.

For example {"=": true} is not possible.

A solution would be to decodeURIComponent all names and values so that my-loader!%3D can be used at the very least.

I recently upgraded a site from Angular2 to Angular4 which cascaded eventually to an upgrade of awesome-typescript-loader which pulled in an up-to-date loader-utils.

However, I found that I got a runtime error in loader-utils when running my site in IE11. Diving deeper, it looks like files like parseQuery in this library are full of fat arrow functions, which break IE11.

Is this library intentionally targeting es6-only? Can these functions be rewritten with the function(){} traditional syntax to prevent this?

Do you want to request a feature or report a bug?
Bug

What is the current behavior?
When you try to use customInterpolateName with Webpack2, we receive an error because the Webpack2 json template does not allow the property customInterpolateName.

Invalid configuration object. Webpack has been initialized using a configuration object that does not match the API schema.
 - configuration has an unknown property 'customInterpolateName'. These properties are valid:
   object { amd?, bail?, cache?, context?, dependencies?, devServer?, devtool?, entry, externals?, loader?, module?, name?, node?, output?, performance?, plugins?, profile?, recordsInputPath?, recordsOutputPath?, recordsPath?, resolve?, resolveLoader?, stats?, target?, watch?, watchOptions? }
   For typos: please correct them.
   For loader options: webpack 2 no longer allows custom properties in configuration.
     Loaders should be updated to allow passing options via loader options in module.rules.
     Until loaders are updated one can use the LoaderOptionsPlugin to pass these options to the loader:
     plugins: [
       new webpack.LoaderOptionsPlugin({
         // test: /\.xxx$/, // may apply this only for some modules
         options: {
           customInterpolateName: ...
         }
       })
     ]

If the current behavior is a bug, please provide the steps to reproduce.
You just have to add an customInterpolateName at the root of any working configuration. For instance:

customInterpolateName: function (url, name, options) {
  return url.replace('[myPath]', '/some/path');
},

What is the expected behavior?
No error.

Please mention other relevant information such as the browser version, Node.js version, webpack version and Operating System.
Node.js: 6.9.2
Webpack 2.2.0
OS: Debian strech/sid

Additional information:

• #29
• 1ba66a7

I was not sure if I should post this here or in the webpack repository.

maybe this is a noob question but I'm wondering why [folder] is relative? what if it just be replaced with directory name?

Thing is I'm using css-loader to generate local classname, which seems to support '[folder]', well since css & js are in the same directory in my project, [folder] is empty.

https://github.com/webpack/loader-utils/blob/master/index.js#L261

if (typeof context !== 'undefined') {
			directory = path.relative(context, resourcePath + "_").replace(/\\/g, "/").replace(/\.\.(\/)?/g, "_$1");
			directory = directory.substr(0, directory.length-1);
		}
		else {
			directory = resourcePath.replace(/\\/g, "/").replace(/\.\.(\/)?/g, "_$1");
		}
		if (directory.length === 1) {
			directory = "";
		} else if (directory.length > 1) {
			folder = path.basename(directory);
		}

Related issue: webpack-contrib/css-loader#463

Calling urlToRequest with an empty string resolves to ./. This behaviour should not be allowed, or rather keep as an empty string and let Webpack handle it.

They have added a .npmignore in 2.5.2 which avoids pulling in 3.5M worth of test and perf files.

Since npm does not want to dedupe devDependencies, I end with 3.5M * N (number of loader plugins), which gets quite big.

no one, no reply...
#46

Since the renaming is a breaking change, it has broken some of its dependent packages (For example: https://github.com/sveltejs/svelte-loader/blob/master/index.js#L2)

I think a "gentler" approach would be to either maintain backward compatibility, or update the major version number. Just FYI. :)

(Originally posted at webpack-contrib/file-loader#60)

I'd like to be able to specify what to mangle through the hash function in order to get the [hash]. In my specific case, I want to hash [path][name]. I would like to have an additional parameter in the [hash] brackets that specifies a pattern (to be interpolated with interpolateName) for what to hash.

Rationale: we're building different versions that are served based on the request origin, but using the same js bundle (and server side code!), but with different file contents (e.g. different images at logo.png). If we were to hash the content, the different file had a different hash, and we could not map it from the one the js bundle requested. We don't want to use [path] in production either because it gives away our file structure. Hence we'd like to hash the path.

I also want to to be able to add two different hashes, one using the path, one using file content, to the generated name. We need this for the version suffix to trick the browser cache, i.e. generate [hash:[path]]/[name]-[hash:6].[ext].

Not a huge issue, but yarn throws the following error upon install: [email protected]: The engine "node" is incompatible with this module. Expected version "^4.0.0". therefore causing the install to fail. I'm more or less pulling this issue to let others know to mitigate this error you must use yarn install --ignore-flags until the node version is fixed/updated in the package.json.

I am using the loader-util to optimise less files
I have seen the following defect appear between versions 0.2.13 and 0.2.14
"malformed URL"
This is becasue in this commit "ee056c9f8fcfef913f64b6b879a59b2747d412fb" (from 3 days ago) you have introduced decodeURIComponent
So the line of code below that used to work, now gives the malformed URL issue
css${mapQ}!autoprefixer${mapQ ? mapQ + '&' : '?'}{ "browsers": ["last 2 versions","> 5%"] }!less${mapQ}

I don't find any string template which let me get chunk name in loaders. In TemplatedPathPlugin, I can get the chunkName by "[name]", and file name by "[file]".

I expect let the templates the same as webpack's template. It will be more cool and easy to use.
Just like the config below.

{
  test: /\.png$|\.jpg$|\.gif$/,
  use: [
    {
      loader: 'url-loader',
      options: {
        name: '[name]/images/[file]-[hash].[ext]',
        limit: '5000'
      }
    }
  ]
}

in my css file, there is a css rule
body {
background-image: url('about:blank');
}
css-loader call loadUtils.isUrlRequest method,
and this method return true, so css-loader try to read this file ,
but u konw this file does not exits, so if there is a bug exits?

Currently deprecation warnings are logged without the name of the loader that caused the issue.

The only way of debugging this is to try each loader one by one to see which one is shooting that warning.

when query is object, there will have a warning like
/ building for production...(node:6852) DeprecationWarning: loaderUtils.parseQuery() received a non-string value which can be problematic, see https:/ /github.com/webpack/loader-utils/issues/56

exports.parseQuery = function parseQuery(query) { var specialValues = { 'null': null, 'true': true, 'false': false }; if(!query) return {}; if(typeof query !== "string") { parseQueryDeprecationWarning(); return query; }
but the api document said it can be object(webpack 2.X)

use webpack bundle an error

Module build failed: Error: A valid query string passed to parseQuery should begin with '?'

who can tell me mhy?

I've found there is a regExp option in interpolateName,
but it only applies to [[name]], how can i apply regex match to [[path]]?

My concern is, when using file-loader, I don't want the exact path, but part of it.

Thanks.

Assuming something like:

module: {
        loaders: [
            { test: /\.js$/, loader: '6to5-loader?runtime=true&experimental=true', exclude: /node_modules/},
        ]
    }

the call loaderUtils.parseQuery(this.query); will return the string "true" instead of the boolean true
Not sure if this is the desired effect, but it's kinda troublesome.

when using symbolic links (in node_modules for instance...) node module system would pick up the "original" path.
This would mess up "stringifyRequest" because different letter can appear and "path.relative" wont work

I fixed this by excluding paths where first character is different

like so:

exports.stringifyRequest = function(loaderContext, request) {
    var splitted = request.split("!");
    var context = loaderContext.context;
    return JSON.stringify(splitted.map(function(part) {
        if(/^\/|^[A-Z]:/i.test(part) && context && part[0] == context[0])
            return "./" + path.relative(context, part).replace(/\\/g, "/");
        return part;
    }).join("!"));
};

my webpack.config.js looks like:

{
    test: /\.(png|jpg|gif)$/,
    loader: 'file-loader?name=assets/img/[name].[ext]'
}

If I do not interfere the file name, just like name=assets/img/[name].[ext] without hash, It may cause big problems.

body {
    background: url(~assets/image/bg.jpg);
}
.loading {
    background: url(~assets/bg.jpg);
}

After I built the project, there was only one file named bg.jpg in the folder assets/img/!

Thx

Looks, like getOptions works only with one config-source. Let me explain 😉

My webpack.config.js looks like this (not exactly the same, but similar and it's enough):

var appConfig = {
	"aaaaaaaaaaaa": 111
}
// ....
var webpackConfig = {
// ....
			{
				test: /[\/\\]package\.json$/,
				loader: "json-string-loader?json1=" + JSON.stringify(appConfig),
				options: {
					json2: { "sssssssssss" : new Date() }
				},
			}

// ....
}

module.exports = webpackConfig

In my *-loader am calling const opt = util.getOptions(this)

Expected

I am waiting for:

opt = {
    json2: { "sssssssssss": "2017-02-21T23:41:56.442Z" },    // from options
    json1: { "aaaaaaaaaaaa": 111 },                          // from query
}

Current result

I have just the options part:

opt = { json2: { "sssssssssss": "2017-02-21T23:41:56.442Z" } }

I could get the content of the query, but I must delete the options sections of the loader from webpack.config.js

Such behavior is implemented here: https://github.com/webpack-contrib/file-loader/blob/v0.10.0/index.js#L21

Feature Request:
Would love the ability to specify my own tokens that tie into a callback of sorts for other webpack loaders.

This is in reference to a Github issue for css-loader.

I've been looking at this most of the day and believe this is turning out to be something with webpack. I'm hoping this looks familiar with someone. I'm getting the following error when running a script that invokes webpack:

``

[email protected] webpack /home/rschmitt/git/gerritstats/GerritStats
webpack --display-error-details --colors --progress --config webpack.config.js
Hash: f1817f83ea7482e48620
Version: webpack 1.15.0
Time: 20910ms
Asset Size Chunks Chunk Names
4713eef7edb06b1e8b4e1e4a6c489a5c.png 19.8 kB [emitted]
a3b60647ef11633dfce07443e8ebcc56.png 19.8 kB [emitted]
bundle.js 3.04 MB 0 [emitted] main
+ 730 hidden modules

ERROR in getOptions is not defined
@ ./src/main/frontend/index.jsx 5:0-28

ERROR in getOptions is not defined
@ ./src/main/frontend/index.jsx 3:0-43
``
There are many more of those ERROR in getOptions in the output. For reference, this is building a package called gerritstats.

This is crossposted in their mailing list as well.

urlToRequest() only checks slash at the beginning of a string to determine if path is absolute or relative. DOS styles paths (c:\path\somewhere) and UNC paths (\device\path\somewhere) are ignored and treated as relative ones.

The deprecation warning is for webpack loader authors, because calling parseQuery with a non-string value can have bad side-effects (see below). If you're a webpack user, you can set process.traceDeprecation = true in your webpack.config.js to find out which loader is causing this deprecation warning. Please file an issue in the loader's repository.

Starting with webpack 2, it is also possible to pass an object reference from the webpack.config.js to the loader. This is a lot more straight-forward and it allows the use of non-stringifyable values like functions.

For compatibility reasons, this object is still read from the loader context via this.query. Thus, this.query can either be the options object from the webpack.config.js or an actual loader query string. The current implementation of parseQuery just returns this.query if it's not a string.

Unfortunately, this leads to a situation where the loader re-uses the options object across multiple loader invocations. This can be a problem if the loader modifies the object (for instance, to add sane defaults). See webpack-contrib/sass-loader#368 (comment).

Modifying the object was totally fine with webpack 1 since this.query was always a string. Thus, parseQuery would always return a fresh object.

Starting with the next major version of loader-utils, we will unify the way of reading the loader options:

• We will remove parseQuery and getLoaderConfig
• We will add getOptions as the only way to get the loader options. It will look like this:

const options = loaderUtils.getOptions(this);

The returned options object is read-only, you should not modify it. This is because getOptions can not make assumptions on how to clone the object correctly.

The splice at https://github.com/webpack/loader-utils/blob/master/lib/interpolateName.js#L18 causes us to run out of emojis when there are many names being mapped.

The new names then start silently being the empty string, which tends to cause problems down the line.

step1

npm install -g yo generator-react-webpack-redux

step2

# Create a new directory, and `cd` into it:
mkdir my-new-project && cd my-new-project

# Run the generator
yo react-webpack-redux

now if you npm start it works.
step3

npm i react-router react-router-proxy-loader -S

step4
modify index.js and add

import 'react-router';
import 'react-router-proxy-loader';

then it throw error above

the error code is

var emojiList = require("emojis-list").filter(function(emoji) {
    return emojiRegex.test(emoji)
});

step5
modify index.js:

import 'react-router';
// import 'react-router-proxy-loader';

there is no error again

I think there are some conflicts between webpack loader-utils emojis-list and react-router-proxy-loader

Currently, getLoaderConfig() accepts exactly one default config property name. I think it should accept an arbitrary number, i.e., 0 or more.

See pull request #34

Summary

In short, I recommend the following:

• If the user passes 1 default config key, the behavior should remain unchanged (I'm not proposing any breaking changes)
• If the user passes more than 1 default config key, search for each from left to right until it finds one in webpack.config.js
• If the user passes 0 default config keys, the equivalent of parseQuery(this.query) should be returned

In all of the above cases, if the user passes a config query parameter, this should be used and all default config parameters should be ignored. This is already how it works when a single default key is passed.

The case for multiple default config keys

A number of loaders accept a config property whose name is the loader name in camelCase, including the Loader suffix. For example, sass-loader accepts a 'sassLoader' config property. Other loaders omit the Loader suffix. For example, postcss-loader simply uses a 'postcss' property.

Since there doesn't seem to be any consensus on whether the config property should end with 'Loader',
I have given users the option of including it or not. The loader will accept either 'ejsHtml' or 'ejsHtmlLoader' as a configuration property name. This is also consistent with the fact that, in the loaders array in webpack.config.js, loaders may be identified with or without the '-loader' suffix. Both 'ejs-html' and 'ejs-html-loader' are picked up by Webpack.

To account for this kind of scenario, it would be nice if getLoaderConfig() accepted an arbitrary number of default config keys, like so:

var config = loaderUtils.getLoaderConfig(this, 'ejsHtml', 'ejsHtmlLoader');

The case for zero default config keys

The case for accepting zero default keys is mainly one of consistency. If, for some reason, a loader only accepts options passed via the query, it should still be able to use getLoaderConfig() to get the parsed query object. These two examples would be equivalent in most cases:

// Currently, this will throw an Error
var config = loaderUtils.getLoaderConfig(this);

var config = loaderUtils.parseQuery(this.query);

The one case in which these would diverge is where the user specifies a custom config query parameter. In this case, getLoaderConfig() would pick it up, which parseQuery() would not.

Issue

At work we came across a problem with loading web-fonts. For some browsers, such as <IE8 there needs to be a query string in the file url ?#iefix, otherwise it does not parse the font file 😓 [source].

@font-face {
  font-family: 'MyFontFamily';
  src: url('./myfont-webfont.eot?#iefix') format('embedded-opentype'), 
     url('./myfont-webfont.woff') format('woff'), 
     url('./myfont-webfont.ttf') format('truetype'),
     url('./myfont-webfont.svg#svgFontName') format('svg');
}

Webpack loader documentation states that there is an this.resourceQuery property inside of the loader context. But didn't find loader-utils using it anywhere.

Suggestion

My suggestion is to add a new token [query], that is the this.resourceQuery including ? symbol.

Examples

// loaderContext.resourcePath = '/myfont-webfont.eot?#iefix'
loaderUtils.interpolateName(loaderContext, '[path][name].[ext]', { content: ... });
// => './myfont-webfont.eot'

// loaderContext.resourcePath = '/myfont-webfont.eot?#iefix'
loaderUtils.interpolateName(loaderContext, '[path][name].[ext][query]', { content: ... });
// => './myfont-webfont.eot?#iefix'

// loaderContext.resourcePath = '/myfont-webfont.eot?#iefix'
loaderUtils.interpolateName(loaderContext, '[path][name].[ext]?[hash]', { content: ... });
// => './myfont-webfont.eot?9473fdd0d880a43c21b7778d34872157'

// loaderContext.resourcePath = '/myfont-webfont.eot?#iefix'
loaderUtils.interpolateName(loaderContext, '[path][name].[ext][query]&[hash]', { content: ... });
// => './myfont-webfont.eot?#iefix9473fdd0d880a43c21b7778d34872157'

I'm not sure if this is a bug, but having this Webpack configuration:

        {
          test: /\.scss$/,
          loader: ExtractTextPlugin.extract({ fallback: 'style-loader', use: 'css-loader!postcss-loader?importLoaders=1!sass-loader?outputStyle=expanded&sourceComments=true'}),
          exclude: /\/custom-apps\/|future/
        },
        {
          test: /\.scss$/,
          loader: 'style-loader!css-loader?modules&localIdentName=[local]___[hash:base64:5]&importLoaders=2!postcss-loader?importLoaders=1!sass-loader?outputStyle=expanded&sourceComments=true',
          include: /\/custom-apps\/|future/
        },

When enabling hot reloading with new webpack.HotModuleReplacementPlugin() plugin, I start getting this error at runtime:

bundle.js:1470 Uncaught SyntaxError: missing ) after argument list

This is the code you get at that line:

/***/ "./app/future/components/BottomRightSubheader/styles/index.scss":
/***/ (function(module, exports, __webpack_require__) {

// style-loader: Adds some css to the DOM by adding a <style> tag

// load the styles
var content = __webpack_require__("./node_modules/css-loader/index.js?modules&localIdentName=[local]___[hash:base64:5]&importLoaders=2!./node_modules/postcss-loader/index.js?importLoaders=1!./node_modules/sass-loader/lib/loader.js?outputStyle=expanded&sourceComments=true!./app/future/components/BottomRightSubheader/styles/index.scss");
if(typeof content === 'string') content = [[module.i, content, '']];
// add the styles to the DOM
var update = __webpack_require__("./node_modules/style-loader/addStyles.js")(content, {});
if(content.locals) module.exports = content.locals;
// Hot Module Replacement
if(true) {
	// When the styles change, update the <style> tags
	if(!content.locals) {
		module.hot.accept("./node_modules/css-loader/index.js?modules&localIdentName=[local]___[hash:base64:5]&importLoaders=2!./node_modules/postcss-loader/index.js?importLoaders=1!./node_modules/sass-loader/lib/loader.js?outputStyle=expanded&sourceComments=true!./app/future/components/BottomRightSubheader/styles/index.scss""./node_modules/css-loader/index.js?modules&localIdentName=[local]___[hash:base64:5]&importLoaders=2!./node_modules/postcss-loader/index.js?importLoaders=1!./node_modules/sass-loader/lib/loader.js?outputStyle=expanded&sourceComments=true!./app/future/components/BottomRightSubheader/styles/index.scss", function() {
			var newContent = __webpack_require__("./node_modules/css-loader/index.js?modules&localIdentName=[local]___[hash:base64:5]&importLoaders=2!./node_modules/postcss-loader/index.js?importLoaders=1!./node_modules/sass-loader/lib/loader.js?outputStyle=expanded&sourceComments=true!./app/future/components/BottomRightSubheader/styles/index.scss");
			if(typeof newContent === 'string') newContent = [[module.i, newContent, '']];
			update(newContent);
		});
	}
	// When the module is disposed, remove the <style> tags
	module.hot.dispose(function() { update(); });
}

Look in your browser for a double "" and you'll see the problem. I think this is somehow related to style-loader as in its code there is the next:

	var query = loaderUtils.getOptions(this) || {};
	return [
		"// style-loader: Adds some css to the DOM by adding a <style> tag",
		"",
		"// load the styles",
		"var content = require(" + loaderUtils.stringifyRequest(this, "!!" + remainingRequest) + ");",
		"if(typeof content === 'string') content = [[module.id, content, '']];",
		"// add the styles to the DOM",
		"var update = require(" + loaderUtils.stringifyRequest(this, "!" + path.join(__dirname, "addStyles.js")) + ")(content, " + JSON.stringify(query) + ");",
		"if(content.locals) module.exports = content.locals;",
		"// Hot Module Replacement",
		"if(module.hot) {",
		"	// When the styles change, update the <style> tags",
		"	if(!content.locals) {",
		"		module.hot.accept(" + loaderUtils.stringifyRequest(this, "!!" + remainingRequest) + ", function() {",
		"			var newContent = require(" + loaderUtils.stringifyRequest(this, "!!" + remainingRequest) + ");",
		"			if(typeof newContent === 'string') newContent = [[module.id, newContent, '']];",
		"			update(newContent);",
		"		});",
		"	}",
		"	// When the module is disposed, remove the <style> tags",
		"	module.hot.dispose(function() { update(); });",
		"}"
	].join("\n");

What takes me to webpack's loader utils stringify request!

I think interpolate function must inherit output hashing settings when compute hash by default, if not overridden manually in query.

1.0.3 is listed as deprecated now.

需增加判断
if(!query) return {};

Upgrade the new version 9.3.0 today. Find out that onSuggestionsFetchRequested not work anymore. The onSuggestionsFetchRequested don`t implement when input value changed. I have no idea why is this. but roll-back to version 9.1.0. It works again!
ps. I use webpack 3.0.0 just now.

As this function returns the loader string that only includes loaders that webpack has already processed, it strikes me that a better name (or an alias) might be something like "getUpstreamRequest".