Optimise bundle sizes by "scalping" @kbn/esql-validation-autocomplete's logic

[gsoldevila]

Summary

The plugins below do not depend (or barely depend on) the @kbn/esql-validation-autocomplete package directly.

• dashboard
• data
• esql
• unifiedHistogram
• unifiedSearch
• inference
• observabilityAssistantApp

Some of them get the whole @kbn/esql-validation-autocomplete code as an indirect dependency through @kbn/esql-utils. After Stratoula's refactors (here and here), we can get rid of this dependency.

For the modules that directly depend on @kbn/esql-validation-autocomplete, using specific path imports helps to dramatically reduce the bundle sizes. E.g. for data plugin, we go from 3.18 Mb to 2.19 Mb.

[elasticmachine]

Pinging @elastic/kibana-esql (Team:ESQL)

[elasticmachine]

Pinging @elastic/kibana-data-discovery (Team:DataDiscovery)

[stratoula]

This is cute but I dont want to lose the enum here. We can try to move this enum somewhere else but I don't want to proceed with the change here because I really need to use the enum

[stratoula]

I get the benefits but not using the enum is not a solution I want to move on with. We can try to move the enum to another package.

[stratoula]

I made the changes here Gerard #212754

I think we can still move on though with your changes in the data plugin (importing directly from the files and not from the index of the package

[gsoldevila]

I made the changes here Gerard #212754
I think we can still move on though with your changes in the data plugin (importing directly from the files and not from the index of the package

Alright! so I count on the enum being defined in a new package (ongoing PR).
I reverted those changes, and now this PR focusses solely on using specific imports, in order to prevent the indirect dependency from being pulled into the bundles. I'm tackling those under src/platform/plugins/shared as a first batch.

I'll rebase once your PR is merged, and then we will be able to assess the savings in bundle sizes.

[stratoula]

Also when this is merged #212772

[stratoula]

@elastic/kibana-operations I want to understand how the bundles sizes are reported on each PR.

So with this PR and the other 2 that got merged before (and Gerard mentions in the description) the data plugin has been significantly decreased. (or this is how it looks when you check the changes locally) But in none of these PRs this reduction has been reported.

Also when we imported the @kbn/esql-validation-autocomplete to the data plugin, the changes from the CI were minimal (not even 1kb)

So I am trying to understand how the bundles sizes from the CI are calculated. Can you help me understand it?

Update: Gerard did a research and we believe that it is production code vs dev code so the advantages of these changes do not have high impact.

⚠️ If this doesnt have an impact I prefer to not move forward with this PR

[elasticmachine]

💔 Build Failed

• Buildkite Build
• Commit: 54af5c7

Failed CI Steps

• Jest Tests #17
• Jest Tests #17

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id	before	after	diff
data	546	531	-15
esql	206	119	-87
unifiedHistogram	199	188	-11
unifiedSearch	394	291	-103
total			-216

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id	before	after	diff
unifiedHistogram	63.3KB	63.3KB	-4.0B

History

• 💔 Build #280341 failed 70009a3
• 💔 Build #280262 failed 28e4c90
• 💔 Build #280134 failed ae5e3e1
• 💔 Build #279968 failed 7f3d4e5
• 💔 Build #279912 failed 379321e

[maximpn]

D&R changes affect a single import and LGTM

[gsoldevila]

Module Count
Fewer modules leads to a faster build time

By the looks of the description, I imagine that by using specific import paths:

• we prevent the modules from being parsed + loaded
• and when it comes to the --dist build, we avoid the need of tree shaking them (as unused dependencies), thus making the build process faster.

I’ve checked a few on-merge builds, and the variations between them are quite large +-5 mins.

For the sake of completeness, I've tried to compare build times for the unifiedSearch module (main vs PR branch):

# main, run the following command 6 times:
# node scripts/build_kibana_platform_plugins --focus unifiedSearch --profile --no-cache --dist

succ 16 bundles compiled successfully after 14.4 sec
succ 16 bundles compiled successfully after 14.3 sec
succ 16 bundles compiled successfully after 14.3 sec
succ 16 bundles compiled successfully after 14.4 sec
succ 16 bundles compiled successfully after 14.8 sec
succ 16 bundles compiled successfully after 14.4 sec

AVERAGE 14.43 sec

# PR branch, run the following command 6 times:
# node scripts/build_kibana_platform_plugins --focus unifiedSearch --profile --no-cache --dist

succ 16 bundles compiled successfully after 13.7 sec
succ 16 bundles compiled successfully after 14 sec
succ 16 bundles compiled successfully after 14.1 sec
succ 16 bundles compiled successfully after 13.5 sec
succ 16 bundles compiled successfully after 13.9 sec
succ 16 bundles compiled successfully after 14 sec

AVERAGE 13.87 sec

We see a ~0.56s reduction in build time for this specific bundle, which represents a ~3.5% improvement.
Hovewer, the Build Kibana distribution step is not critical in the CI pipeline, so all in all I don’t think we’re gonna see any noticeable benefit on CI times.

With these figures in mind, I'm closing this PR, as the benefit does not seem worth polluting the import statements.