Force developers to use async imports on key rendering APIs

[joshdover]

In order to keep Kibana's frontend lean, we may want to consider changing some of the APIs we have for rendering in order to force applications to use async imports in the spots where plugins most often import more code than they should.

For example, it'd be great to be able to support something like:

core.application.register({
  id: 'myApp',
  renderModule: './application/render',
})

The challenge with this will be figuring out how to make this work with Webpack's async chunk feature. Currently, it will only create an async chunk if there is an import('./application/render') call and using import() with dynamic values leads to Webpack trying to build bundles out of all the possible modules that could be referenced.

I haven't investigated how we could make this work, but I suspect there may be a way using Webpack's "magic comments" and some require.resolve magic.

If we do find a way to make this work, we should also apply it to APIs much as Embeddables so that we can be sure that embeddables can be registered without importing very much code into a plugin's primary bundle.

[elasticmachine]

Pinging @elastic/kibana-platform (Team:Platform)

[elasticmachine]

Pinging @elastic/kibana-operations (Team:Operations)

[spalger]

I think we probably need to rely on eslint here.

I don't think we'll be able to use magic comments to accomplish this. require.resolveWeak() could be used to get the module id for the remote module, but we can't know the chunk name/id without explicitly defining it somewhere with a import(/* webpackChunkName: "app" */ './application').

It seems like it would be a lot easier to validate that render functions use import(), maybe more.

[joshdover]

@restrry to investigate how many plugins are violating this now to determine impact & whether or not this is worth the effort right now

[tylersmalley]

Checking to see if there is something we see as actionable here or if we want to close it. At the end of the day, I think teams need to own their async logic and not require us to do anything magical. cc @pauldotpower @stacey-gammon

[stacey-gammon]

I think we could close this. I think the time would be better spent focusing on page load time metrics, plus education regarding async imports, in order to give teams the motivation and knowledge to leverage them. We'll never be able to catch and prevent all of these sync imports that should actually be async.

[pgayvallet]

I'll go ahead and close, then.