-
-
Notifications
You must be signed in to change notification settings - Fork 874
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
Webpack performance plugin in CI will make build fail #671
Comments
Ran into same issue. Although I think removal seems a bit of a disservice. You can use the module.exports = {
// ...
modify(defaultConfig, { target, dev }, webpack) {
if (!dev) {
config.performance = Object.assign({}, {
maxAssetSize: 100000,
maxEntrypointSize: 300000,
hints: false
})
}
return config
}
} |
Hola! So here's the deal, between open source and my day job and life and what not, I have a lot to manage, so I use a GitHub bot to automate a few things here and there. This particular GitHub bot is going to mark this as stale because it has not had recent activity for a while. It will be closed if no further activity occurs in a few days. Do not take this personally--seriously--this is a completely automated action. If this is a mistake, just make a comment, DM me, send a carrier pidgeon, or a smoke signal. |
ProBot automatically closed this due to inactivity. Holler if this is a mistake, and we'll re-open it. |
I too have ran into this, and think it should be scrutinized in future versions. I enjoy the gesture of built in performance budgeting, but the 52KiB allowance is rather small. |
I agree, but what I found problematic was that the
And on my local machine, it looks like this:
You can see that the final build is much smaller than the 244KiB limits set as default by webpack's I have added @rohidee's suggestion to our FYI, you can test how your CI might build your app but adding |
I've also experienced what @mrmartineau stated. I think it's a good thing that there is a default asset size limit; it keeps you sharp about what you include in your entry bundle. However, I would expect the same chunks to be made with and without the CI environment variable set. I understand that there is a difference between a warning and an error on the CI, but I don't understand why there are more chunks when bulding locally as opposed to building in the CI. |
Can we reopen this issue by any chance? I'm still getting different bundle sizes depending on CI env variable. I tried looking into the default config here but found nothing of interest. My workaround was to set the CI build script to |
I got around this by:
In doing this I realized that it's not very reasonable to expect razzle to calculate these hints based on gzip filesize. it's all done by webpack performance hints plugin, which operates on non-gzip. My razzle.config.js: const logger = require('razzle-dev-utils/logger')
module.exports = {
plugins: [
useRuntimePortEnvironmentVariable,
WebpackSplitChunksRazzlePlugin({
// include both initial and async imports for chunking, not just initial
chunks: 'all',
// default is 3
maxInitialRequests: Infinity,
// default is 30000
minSize: 0,
}),
WebpackPerformanceHintsRazzlePlugin({
// Use a custom assetFilter to not warn about big source maps or vendor bundle
assetFilter: function(assetFilename) {
const isSrcMap = /\.map$/.test(assetFilename)
const isVendorBundle = /vendor/.test(assetFilename)
return ! (isSrcMap || isVendorBundle)
}
}),
'typescript',
],
}
function NoopRazzlePlugin() {
return function NoopRazzlePluginFunc(config) {
return config
}
}
function WebpackPerformanceHintsRazzlePlugin(pluginOptions) {
return function WebpackPerformanceHintsRazzlePluginFunc(config) {
return {
...config,
performance: {
...config.performance,
assetFilter: function(assetFilename) {
const isSrcMap = /\.map$/.test(assetFilename)
const isVendorBundle = /vendor/.test(assetFilename)
return ! (isSrcMap || isVendorBundle)
}
}
}
}
}
/**
* Update config to use process.env.PORT provided at *runtime*, not build-time, which is the default behavior
*/
// https://github.com/jaredpalmer/razzle/issues/906#issuecomment-467046269
function useRuntimePortEnvironmentVariable(config, { target, dev }, webpack) {
const appConfig = Object.assign({}, config);
// @BUG: Do not inline certain env vars; https://github.com/jaredpalmer/razzle/issues/356
if (target === 'node') {
const idx = appConfig.plugins.findIndex(plugin => plugin.constructor.name === 'DefinePlugin');
const { definitions } = appConfig.plugins[idx];
const newDefs = Object.assign({}, definitions);
delete newDefs['process.env.PORT'];
delete newDefs['process.env.HOST'];
delete newDefs['process.env.PUBLIC_PATH'];
appConfig.plugins = [].concat(appConfig.plugins);
appConfig.plugins[idx] = new webpack.DefinePlugin(newDefs)
}
return appConfig;
}
/**
* Razzle Plugin to split common libraries into a chunk named 'vendor'.
* The idea is that this bundle will change way less often than the src code
* of this app, so will mean less average download size because vendor can be cached.
* Taken from https://github.com/jaredpalmer/razzle/tree/master/examples/with-vendor-bundle
*/
function WebpackSplitChunksRazzlePlugin(pluginOptions={}) {
return function WebpackSplitChunksRazzlePluginFunc (razzleConfigBefore, { target, dev }, webpack) {
const config = Object.assign({}, razzleConfigBefore);
// Change the name of the server output file in production
if (target === 'web') {
// modify filenaming to account for multiple entry files
config.output.filename = dev
? 'static/js/[name].js'
: 'static/js/[name].[hash:8].js';
// I think these are the default that webpack sets
// https://webpack.js.org/plugins/split-chunks-plugin/#optimizationsplitchunks
const defaultSplitChunksConfig = {
chunks: 'async',
minSize: 30000,
maxSize: 0,
minChunks: 1,
maxAsyncRequests: 5,
maxInitialRequests: 3,
automaticNameDelimiter: '~',
automaticNameMaxLength: 30,
name: true,
cacheGroups: {
vendors: {
test: /[\\/]node_modules[\\/]/,
priority: -10
},
default: {
minChunks: 2,
priority: -20,
reuseExistingChunk: true
}
}
}
config.optimization.splitChunks = {
...defaultSplitChunksConfig,
...config.optimization.splitChunks,
...pluginOptions,
}
}
return config;
}
} |
* Add build step to CI action * Update Razzle asset limit to 400kB Based on: jaredpalmer/razzle#671
A warning to anyone who stumbles here: for whatever reason, the solution proposed above with |
The problem
Currently, Webpack has a performance default of 244KiB (un-gzipped) where if
process.env.CI = true
is set, the build will fail complaining about degraded performance.Razzle, without any additions, is already at 192KiB (un-gzipped) excluding any CSS (the above counts CSS as well).
Any reasonable additions to the base Razzle project will basically make the build fail if you are running it in a CI.
entrypoint size limit: The following entrypoint(s) combined asset size exceeds the recommended limit (244 KiB). This can impact web performance. Entrypoints: client (248 KiB) static/css/bundle.c91c1092.css static/js/bundle.5bcffbdf.js webpack performance recommendations: You can limit the size of your bundles by using import() or require.ensure to lazy load some parts of your application. For more info visit https://webpack.js.org/guides/code-splitting/
Steps to reproduce
core-js
polyfills to browsers don't break -assign, find, from, promise
react-autosuggest
for exampleCI=true npm run build
and watch it fall downRecommendations
I think it's confusing to the bundle size error on uncompressed yet we show the compressed size if the build succeeds. Also 244KiB of uncompressed JavaScript has never been an indicator of degraded performance - people should be using performance monitoring and budgeting to understand when something degrades user experience.
Several options here are:
webpack.performance
entirely from the default Razzle configThe text was updated successfully, but these errors were encountered: