mirror of
https://github.com/elastic/kibana.git
synced 2025-04-25 10:23:14 -04:00
4a5ba237df
* [timelion] remove last remaining amd modules
* [eslint-config-kibana] remove env.amd
* [webpack] use absolute loader names
* [webpack] remove absolute node_modules/ imports
* [webpack] upgrade to webpack 3
* [uiFramework] make webpack build compatible with v3
* [eslint-import-resolver] use https://github.com/elastic/eslint-import-resolver-kibana/pull/21
* [baseOptimizer] don't break when pkg has no dependencies
* [optimize] remove unnecessary json-loader
* [optimize] remove local references to webpack vars
* [eslint] upgrade to eslint-import-resolver-kibana 0.9.0
* [baseOptimizer] comment tweaks
* [baseOptimizer] remove loader pinning
In webpack 1 the loaders defined here were resolved relative to the file they were going to load, which meant that plugins in other projects could accidentally overwrite the loaders Kibana was trying to use, which is why the aliases were used to enforce proper resolution.
In webpack 2 loaders are now resolved relative to the webpackConfig.context, which is set to the root of the Kibana repo. See https://webpack.js.org/configuration/module/#useentry
* [webpack] rely on kibana webpack shims before checking node_modules
(cherry picked from commit f60639fccb)
103 lines
No EOL
3.9 KiB
Text
103 lines
No EOL
3.9 KiB
Text
[[development-dependencies]]
|
|
=== Managing Dependencies
|
|
|
|
While developing plugins for use in the Kibana front-end environment you will
|
|
probably want to include a library or two (at least). While that should be
|
|
simple to do 90% of the time, there are always outliers, and some of those
|
|
outliers are very popular projects.
|
|
|
|
Before you can use an external library with Kibana you have to install it. You
|
|
do that using...
|
|
|
|
[float]
|
|
==== npm (preferred method)
|
|
|
|
Once you've http://npmsearch.com[found] a dependency you want to add, you can
|
|
install it like so:
|
|
|
|
["source","shell"]
|
|
-----------
|
|
npm install --save some-neat-library
|
|
-----------
|
|
|
|
At the top of a javascript file, just import the library using it's name:
|
|
|
|
["source","shell"]
|
|
-----------
|
|
import someNeatLibrary from 'some-neat-library';
|
|
-----------
|
|
|
|
Just like working in node.js, front-end code can require node modules installed
|
|
by npm without any additional configuration.
|
|
|
|
[float]
|
|
==== webpackShims
|
|
|
|
When a library you want to use does use es6 or common.js modules but is not
|
|
available on npm, you can copy the source of the library into a webpackShim.
|
|
|
|
["source","shell"]
|
|
-----------
|
|
# create a directory for our new library to live
|
|
mkdir -p webpackShims/some-neat-library
|
|
# download the library you want to use into that directory
|
|
curl https://cdnjs.com/some-neat-library/library.js > webpackShims/some-neat-library/index.js
|
|
-----------
|
|
|
|
Then include the library in your JavaScript code as you normally would:
|
|
|
|
["source","shell"]
|
|
-----------
|
|
import someNeatLibrary from 'some-neat-library';
|
|
-----------
|
|
|
|
[float]
|
|
==== Shimming third party code
|
|
|
|
Some JavaScript libraries do not declare their dependencies in a way that tools
|
|
like webpack can understand. It is also often the case that libraries do not
|
|
`export` their provided values, but simply write them to a global variable name
|
|
(or something to that effect).
|
|
|
|
When pulling code like this into Kibana we need to write "shims" that will
|
|
adapt the third party code to work with our application, other libraries, and
|
|
module system. To do this we can utilize the `webpackShims` directory.
|
|
|
|
The easiest way to explain how to write a shim is to show you some. Here is our
|
|
webpack shim for jQuery:
|
|
|
|
["source","shell"]
|
|
-----------
|
|
// webpackShims/jquery.js
|
|
|
|
module.exports = window.jQuery = window.$ = require('../node_modules/jquery/dist/jquery');
|
|
require('ui/jquery/findTestSubject')(window.$);
|
|
-----------
|
|
|
|
This shim is loaded up anytime an `import 'jquery';` statement is found by
|
|
webpack, because of the way that `webpackShims` behaves like `node_modules`.
|
|
When that happens, the shim does two things:
|
|
|
|
. Assign the exported value of the actual jQuery module to the window at `$` and `jQuery`, allowing libraries like angular to detect that jQuery is available, and use it as the module's export value.
|
|
. Finally, a jQuery plugin that we wrote is included so that every time a file imports jQuery it will get both jQuery and the `$.findTestSubject` helper function.
|
|
|
|
Here is what our webpack shim for angular looks like:
|
|
|
|
["source","shell"]
|
|
-----------
|
|
// webpackShims/angular.js
|
|
|
|
require('jquery');
|
|
require('../node_modules/angular/angular');
|
|
require('../node_modules/angular-elastic/elastic');
|
|
require('ui/modules').get('kibana', ['monospaced.elastic']);
|
|
module.exports = window.angular;
|
|
-----------
|
|
|
|
What this shim does is fairly simple if you go line by line:
|
|
|
|
. makes sure that jQuery is loaded before angular (which actually runs the shim above)
|
|
. load the angular.js file from the npm installation
|
|
. load the angular-elastic plugin, a plugin we want to always be included whenever we import angular
|
|
. use the `ui/modules` module to add the module exported by angular-elastic as a dependency to the `kibana` angular module
|
|
. finally, export the window.angular variable. This means that writing `import angular from 'angular';` will properly set the angular variable to the angular library, rather than undefined which is the default behavior. |