webpackShims

webpackShims is how Kibana modifies the way that certain libraries are loaded using webpack, without having to create complex overrides in the webpack configuration.

hacking module resolution

Webpack follows the same approach that node.js popularized when resolving the location of modules, which is detailed in Resolving Require Paths. In that article you will see that as webpack moves up from the directory of the file it will look for a named module at webpackShims/{name} right before it looks for node_modules/{name}. This allows us to override the file an import resolves to by placing strategically named files into a webpackShims directory.

For instance, if a file contained the import statement import 'angular' node.js' conventions suggest that webpack should load the node_modules/angular module, but if we create webpackShims/angular.js then webpack will instead load that. It then becomes the job of webpackShims/angular.js to load the actual angular module, which it could do by importing a more specific path, say node_modules/angular/angular.js.

This is beneficial for a few reasons:

1. gives us the ability to import dependencies for a module before it is loaded [example]
2. allows us to change the export value provided by a module [example]
3. it allows us to override modules local to where it's used [example]

• the version of ace linked to in the example is a customized version used for sense
• kibana also uses the ace editor, but because webpackShims follows the node.js' approach both kibana and sense can have different versions at the same time.

4. it allows automatically including plugins or mixins [example]

uses

shimming

The primary use case for webpackShims is to shim a 3rd party library, see the 3rd party dependencies article for more details.

including external code

Since node_modules is ideally managed by npm (and not git) downloading code from a 3rd party prevents you from using the comfy import "name"; syntax and requires relative file paths be used. Instead, code from 3rd parties can be placed in the webpackShims directory and then referred to as you would a npm module.

excluding code from transpilation

This is a fairly strange use case, but it could be done if necessary. Since webpackShims is not designed for application code the entire directory is excluded from babel transpilation. This means that you can include large, complex, build outputs here and prevent the optimization process from grinding to a halt (just a slow crawl).

including external code from transpilation

The last two points work together quite nicely 💯