[optimizer] Disable symlink resolution by default in production

[tylersmalley]

This provides a small ~5% gain in build time and is recommended by the Webpack team. https://webpack.js.org/guides/build-performance/#resolving

This adds a configuration option optimize.resolveSymlink which is false in production and defaults to true in development. In the future, we might consider this always defaulting to false.

[epixa]

In what circumstances would you want to resolve symlinks in development but not in production?

[tylersmalley]

If you're using yarn link or npm link as they use symlinks under the hood.

We could disable this for development by default as well, but we would need to educate folks on it. I figure we let devs disable it, that way they know it exists should they need to work on a dependency locally.

[kimjoar]

Can you hold off on this a couple days? I'm trying to get the different build things for new platform PR'd, and I think they might end up conflicting with this (by using symlinks for Kibana plugins, also in production).

[tylersmalley]

@kjbekkelund, no problem. Will do.

[tylersmalley]

@kjbekkelund, is this something we are still able to do?

[elasticmachine]

💔 Build Failed

• continuous-integration/kibana-ci/pull-request

[kimjoar]

We don't need symlinking in production yet (we put Kibana packages in the top-level node_modules when we build Kibana so they are available to plugins that are put in the plugins/ folder in production, see #16509).

However, at some point I think we might want to enable plugins to share packages, e.g. x-pack specific packages or Canvas specific packages. There are some details in #16481. Not sure we'll ever get there though, but I think we could get there.

So I'm not sure if we want to merge this or not. To me it seems like it isn't worth it in the near-term, as it can complicate things for us when we want to push further on the packages stuff.

[tylersmalley]

Closing this for now.