[chore] Reuse bundled lodash and lodash/fp dependency#217467
[chore] Reuse bundled lodash and lodash/fp dependency#217467dej611 merged 14 commits intoelastic:mainfrom
Conversation
|
Pinging @elastic/kibana-operations (Team:Operations) |
PhilippeOberti
left a comment
There was a problem hiding this comment.
LGTM for the Threat Hunting Investigations team!
pmuellr
left a comment
There was a problem hiding this comment.
ResponseOps changes LGTM
afharo
left a comment
There was a problem hiding this comment.
Core changes are all server-side. LGTM.
|
Have we considered adding a linter rule to keep the imports this way? |
Yes, but |
💚 Build Succeeded
Metrics [docs]Module Count
Async chunks
Page load bundle
Unknown metric groupsESLint disabled line counts
Total ESLint disabled count
History
|
rylnd
left a comment
There was a problem hiding this comment.
Detection Engine changes LGTM.
## Summary After elastic#217202 and elastic#217034 this the another attempt with `lodash` and `lodash/fp`. In short: `lodash` and `lodash/fp` have a special webpack treatment as they are imported within the shared bundle. Now webpack is not smart enough to understand that `import camelCase from 'lodash/camelCase';` is still pointing to `lodash` and it thinks that `lodash/camelCase` is a different package, de-optimizing the bundling caching system. So I’ve tweaked the import to make it point to the shared bundle and save few kbs here and there
## Summary Similar to #217034, #217202 and #217467 this time applied to `react-use`. This is a slightly different approach than #217034 as we're caching here only the most common/frequently used methods from the `react-use` library and leaving the rest to be loaded within the specific plugin chunks. What this PR does it fundamentally: * adds `7.x kb` to the shared bundle * overall the startup bundle size shrinks about `3.5 kb` * the async bundle size shrinks of about `350 kb` (mainly due to 3 imports which were targeting `react-use/lib`). An alternative approach would be to just fix the async import strings in there, but I thought to it was worth it to make the long step here. Feedback appreciated.
## Summary After elastic#217202 and elastic#217034 this the another attempt with `lodash` and `lodash/fp`. In short: `lodash` and `lodash/fp` have a special webpack treatment as they are imported within the shared bundle. Now webpack is not smart enough to understand that `import camelCase from 'lodash/camelCase';` is still pointing to `lodash` and it thinks that `lodash/camelCase` is a different package, de-optimizing the bundling caching system. So I’ve tweaked the import to make it point to the shared bundle and save few kbs here and there
) ## Summary Similar to elastic#217034, elastic#217202 and elastic#217467 this time applied to `react-use`. This is a slightly different approach than elastic#217034 as we're caching here only the most common/frequently used methods from the `react-use` library and leaving the rest to be loaded within the specific plugin chunks. What this PR does it fundamentally: * adds `7.x kb` to the shared bundle * overall the startup bundle size shrinks about `3.5 kb` * the async bundle size shrinks of about `350 kb` (mainly due to 3 imports which were targeting `react-use/lib`). An alternative approach would be to just fix the async import strings in there, but I thought to it was worth it to make the long step here. Feedback appreciated.
Summary
After #217202 and #217034 this the another attempt with
lodashandlodash/fp.In short:
lodashandlodash/fphave a special webpack treatment as they are imported within the shared bundle.Now webpack is not smart enough to understand that
import camelCase from 'lodash/camelCase';is still pointing tolodashand it thinks thatlodash/camelCaseis a different package, de-optimizing the bundling caching system.So I’ve tweaked the import to make it point to the shared bundle and save few kbs here and there