I noticed the following message while watching the build output: ``` 00:33:19.131 │ info [kibana] > /var/lib/jenkins/workspace/elastic+kibana+pull-request+multijob-x-pack/install/kibana/bin/kibana --optimize.useBundleCache=true --env.name=development --logging.json=false --server.port=5620 --optimize.watchPort=5630 --optimize.watchPrebuild=true --status.allowAnonymous=true --elasticsearch.url=http://elastic:changeme@localhost:9220 --elasticsearch.username=elastic --elasticsearch.password=changeme --server.uuid=5b2de169-2785-441b-ae8c-186a1936b17d --xpack.xpack_main.telemetry.enabled=false --xpack.security.encryptionKey="wuGNaIhoMpk5sO4UBxgr3NyW1sFcLgIf" --optimize.enabled=true --xpack.reporting.capture.browser.type=chromium --xpack.spaces.enabled=false 00:33:38.533 │ proc [kibana] log [23:20:25.923] [info][optimize] Optimizing and caching bundles for ml, stateSessionStorageRedirect, status_page, timelion, graph, monitoring, login, logout, dashboardViewer, apm, canvas, infra and kibana. This may take a few minutes 00:34:12.650 │ proc [kibana] [BABEL] Note: The code generator has deoptimised the styling of "/var/lib/jenkins/workspace/elastic+kibana+pull-request+multijob-x-pack/install/kibana/node_modules/x-pack/plugins/infra/node_modules/lodash/lodash.js" as it exceeds the max of "500KB". 00:36:11.346 │ proc [kibana] log [23:22:58.721] [info][optimize] Optimization of bundles for ml, stateSessionStorageRedirect, status_page, timelion, graph, monitoring, login, logout, dashboardViewer, apm, canvas, infra and kibana complete in 152.79 seconds ``` The "code generator has deoptimised" line specifically raised a red flag as babel shouldn't be running on node_modules. We have admittedly weak regular expressions in two places to enforce this. The first is in49071132c3/src/setup_node_env/babel_register/register.js (L42)
, which I verified matched `node_modules` directories within the `node_modules/x-pack` directory, but the other is49071132c3/src/optimize/base_optimizer.js (L152-L154)
which does not. It only excludes files from babel in webpack if they are within a node_modules directory that is a direct child of `node_modules/xpack`, but with InfraOps and Canvas we now have node_module directories at `plugins/*/node_modules`. This should probably be fixed by preventing plugins from installing their own node_modules, but since that would involve upgrading/moving plugins between major versions of dependencies like lodash that's somewhat impractical from where I stand, so instead I've just updated the webpack module rule to exclude any `node_modules/xpack/**/node_modules` directory.
This commit is contained in:
parent
3ba2d848b2
commit
1f59c294da
|
@ -151,7 +151,7 @@ export default class BaseOptimizer {
|
|||
{
|
||||
test,
|
||||
include: /[\/\\]node_modules[\/\\]x-pack[\/\\]/,
|
||||
exclude: /[\/\\]node_modules[\/\\]x-pack[\/\\]node_modules[\/\\]/,
|
||||
exclude: /[\/\\]node_modules[\/\\]x-pack[\/\\](.+?[\/\\])*node_modules[\/\\]/,
|
||||
}
|
||||
];
|
||||
};
|
||||
|
|
Loading…
Reference in a new issue