-
-
Notifications
You must be signed in to change notification settings - Fork 26.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use url-loader with limit 10k as a default loader. #1059
Conversation
68f230f
to
0ea4719
Compare
Travis failing is because of line 78,
That is because the logo.svg is now packed into the bundle. |
0ea4719
to
68f8aa0
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks very good, nice work @bebbi! I had a couple of suggestions how to simplify things even further.
{ | ||
test: /\.(mp4|webm|wav|mp3|m4a|aac|oga)(\?.*)?$/, | ||
test: /\.(eot|otf|svg|ttf|woff|woff2)(\?.*)?$/, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we'll be able to get rid of this separate loader for web fonts, since these file extensions are handled by the default url-loader
above.
The only difference left seems to be that this config loads files outside the src
folder. I'd say let's simplify the rules for handling files further:
- JavaScript is compiled with Babel only if it's in the
src
folder. - All the other file types can be in any folder.
Then we can simply drop the special handling for web fonts, and the ways different file types are handled is easy to predict and understand.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see a reason to handle webfonts separately: If you have a font in four formats and all of them are less then 10K you’ll have four inlines files which is probably not what you expected. But that means we need file-loader here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can see a similar argument could be made for other file types too. If anything, that could mean we need to make the size threshold smaller. Because handling them separately would mean going back to maintaining a whitelist, I would not make an exception for those file types at least without more data about how real bundle sizes are affected.
// "url" loader works like "file" loader except that it embeds assets | ||
// smaller than specified limit in bytes as data URLs to avoid requests. | ||
{ | ||
test: /\.(?!(js|jsx|css|json|html)(\?.*)?$)[^\.]+$/, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps we could make the regex more readable by making use of the exclude
option and simply listing the patterns handled by other loaders verbatim?
exclude: [
/\.(js|jsx)$/,
/\.css$/,
/\.json$/
]
Then we wouldn't have to do a negative lookahead and the list would also be very easy to keep up to date if new loaders get added.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree with adding to exclude. But don't we need to add the querystring bit (\?.*)?
with some/many of them? I don't have experience with this. If so, I suggest a single line
/\.(js|jsx|etc)(\?.*)?$/
which should be just as easy to edit. Agree?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The idea was to include exactly the same regexes used in those other loaders, so each file is either handled by one of them or handled by this loader. The JS, JSON and CSS loader configs we have don't match query strings in their regexes, so there's no need to match them here either. I think the whole loader config could be as simple as:
{
test: /./,
loader: 'url',
query: {
limit: 10000,
name: 'static/media/[name].[hash:8].[ext]'
},
exclude: [
/\.(js|jsx)$/,
/\.css$/,
/\.json$/
]
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
exclude: /\.(js|jsx|css|json)$/
would work the same way, but then it's no longer the same regex, so it's harder to notice if we introduce discrepancies between them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
makes sense - it escaped me that the other loaders all don't have the querystring. will update.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also it seems that a loader without the test
regex will match all files, so we can also omit that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done (added a note about missing test
for clarity). Squashed to keep history clean.
@@ -71,11 +71,10 @@ npm install | |||
|
|||
# Test local build command | |||
npm run build | |||
# Check for expected output | |||
# Check for expected output (logo.svg is now inlined) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's two similar checks further down this file that still fail the test in Travis. Feel free to remove them too. Also the existing # Check for expected output
comment is probably enough since nobody will remember logo.svg
used to be not inlined. 😉
Loads all files not already handled by other loaders. Also, switch image loading from file loader to url-loader.
68f8aa0
to
77e250c
Compare
Looks good to me! |
// by other loaders with the url loader. | ||
// Note: This list needs to be updated with every change of extensions | ||
// the other loaders match. | ||
// E.g., when adding a loader for a new supported file extension, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a rather big gotcha. Can we place it last in the file or something?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've put this loader first for exactly that reason :-). Maybe add another comment to all other loaders?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The gotcha would still apply right? Then I guess it doesn't make a difference.
I wish we could find a way to "validate" the config automatically though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suppose the "negative" loader could be calculated from the others, at the price of making it imperative.
The least-invasive change might remove the loader and add a line at the end of the config something like:
module.exports.loaders.push(fn(module.exports.loaders));
Would you like something along these lines?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or perhaps it would make more sense to run a validation function at the end of the config and throw a descriptive error if negative tests not matching the other loaders? Con: only naive string comparison for regexes, but I think it shouldn't be a problem.
// we need to add the supported extension to this loader too. | ||
// Add one new line in `exclude` for each loader. | ||
// | ||
// "file" loader makes sure those assets get served by WebpackDevServer. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Comment about WDS shouldn't end up in the production config.
Notice how it wasn't before this change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Apologies. I re-arranged a few things and tried to mirror exactly - this escaped.
Let me know if you want me to follow up with another PR on this and whatever decision for above.
What about this line? It will produce different behaviors now. Please search for all whitelists. For example by searching for |
looks like it's these
|
Yep, looks so! |
Let's fix all of these in a single followup PR? Thanks! |
I'll look into all tomorrow AM UTC. |
Thanks, I appreciate it! @fson Let's block the release on this at least. |
Loads all files not already handled by other loaders. Also, switch image loading from file loader to url-loader.
Loads all files not already handled by other loaders. Also, switch image loading from file loader to url-loader.
Loads all files not already handled by other loaders. Also, switch image loading from file loader to url-loader.
Loads all files in appSrc not already handled by other loaders.
Also, switch image loading from file loader to url-loader.
Fixes #667.