Vue-Cli not exporting default during build



I am currently migrating a Vue in browser app to vue-cli that is a kibana plugin. I can successfully run the app using vue serve and access the app through a browser. Where I am getting tripped up is exporting a factory that should init the kibana app inside of the kibana system.

I have cleared out my cache and tried various options between exporting as umd/common and a full package build.

Vue.config is

module.exports = {
  // Inline all of the CSS things
  css: {
    extract: false,
  chainWebpack: config => {
    // So that we get a single bundle
  configureWebpack: config => {
    config.output.libraryExport = 'default';

The kibana entry looks like this. It imports my app which runs successfully using vue serve.

function initKibanaPlugin($scope, $element, $http, chrome) {
    store.commit('initFromKibanaPlugin', {$http, chrome});
    const vm = new Vue({
        el: $element[0],
        provide: {
        render: (h) => h(App),

// cleanup when we remove the scope
    $scope.$on('$destroy', () => {

export default initKibanaPlugin;

The kibana app that is uses the built library like this

import { uiModules } from 'ui/modules';
import chrome from 'ui/chrome';

import elasticIq from '../vue_src/dist/iq2.common';

const app = uiModules.get('app/elastic-iq');

app.config(stateManagementConfigProvider =>

chrome.setRootController('iq2', elasticIq);

However the built library looks like this when i do a build and import from dist.



So your issue is that you want to export this function as the export of your library, but when you log it, you get a Vue constructor?

What’s the exact build command you used? Snd. In which file is that plugin function that you want to export?

It seemed likeyou build with the wrong entry file…


Thanks for looking. Correct.

I’ve tried quite a few different options on it. I’ve tried this with and without a target of lib.

"build": "vue-cli-service build --target lib --name iq2",

I put the initKibanaPlugin in the main.ts file with the theory that it would reduce the number of “things” that could be off.


Alrighty, so dug a little deeper into the compiled output here and it looks like it is not using the correct entry point. So either i have something configured wrong or there is some bug.

I posted a pared down repo for this, the reason i am exporting a function here is that kibana is an angular app and i would also like to distribute this in a couple other ways (chrome app for instance)

I inspected the output of the vue-cli and the entry looks correct

  entry: {
    app: [


@LinusBorg Any thoughts on this or direction i could go to help isolate further. Posted an example above. Thank you!


From the docs:

vue-cli-service build --target lib --name myLib [entry]

The entry can be either a .js or a .vue file. If no entry is specified, src/App.vue will be used.

Since you don’t provide an entry file, you’re bundling App.vue, which explains why you are seeing a VueComponent Constructor in your console.

vue-cli-service build --target lib --name myLib src/main.ts


:man_facepalming: Awesome thanks! Thinking of ways to improve this for future people.

Think where i was confused is that the entry in my webpack export inspection was main.ts. Am i interpreting this incorrectly or is the result of this what i would use in a standard webpack webpack setup?

$ yarn vue-cli-service inspect | grep -B 0 -A 5 entry 
  entry: {
    app: [

Also may not be avoidable b/c i think it was just me not paying attention, but i saw this line and didn’t realize it was in Web Components and didn’t continue reading the next line that says it only does the main wrapping in dev mode.

Note that the entry should be a *.vue file. Vue CLI will automatically wrap and register the component as a Web Component for you, and there's no need to do this yourself in main.js. 


Unfortunately the inspect command currently only shows the config for --target app (the default), it doesn’t offer a way to inspect the final webpack config when using --target lib.

Since the lib mode does some adjustments to the webpack config compared to the app config, this leads to some blind spots.