Build using @vue/cli and rollup

[davidyuk]

As I understand, in #118 and #120 Sadi proposes to build

• a set of "frequently used" components
• every component separately

as several UMD libraries. This will make a developer import every component separately, pointing proper file name to reduce unused code in the app bundle. I think much better to setup tree shaking instead. I have found that the components library can be build using "vue-cli":

• it supports several build targets that can be useful for our package (web components, and async web components)
• it uses own webpack configs that can be changed through vue.config.js file (less work to maintain config files in our package)

But libraries generated by this package can't be tree-shaked:

unfortunately, webpack currently does not support ES modules output format for bundles yet (https://cli.vuejs.org/guide/build-targets.html#library)

I believe that its support will be implemented later, for now, I propose to build es module using rollup according to this guide from Vue documentation.

[sadiqevani]

But libraries generated by this package can't be tree-shaked:

In relation to tree-shaking by definition means:

tree shaking is a term commonly used in the JavaScript context for dead-code elimination. It relies on the static structure of ES2015 module syntax, i.e. import and export. The name and concept have been popularized by the ES2015 module bundler rollup.

So lets take it by context:

• A library is a bundle of code that acts as a function and has no side effects (hopefully)
• So technically when you provide someone with a library, you wanna avoid giving him code you haven't written
• So this brings us to the exclusion of external code when you bundle the modules (since the same dev might have the same libraries installed as dependencies in his repository)
• Which brings us to the usage of tree-shaking which I think its best case scenario is when you're building an app to serve it to the user

To backup my claim, just randomly searched on google with treeshaking libraries and this came up: https://github.com/webpack/webpack/issues/5801 which the first two comments suggest doing as i've mentioned above

Now the only case I see tree-shaking as a viable option is when you're bundling to export it as a global function over the browser (similar to jQuery <script src=""> inclusion), which currently there's no support for and the use-case for it is quite low.

[davidyuk]

@sadiqevani Please do not confuse Externals and Tree Shaking features of Webpack. In #120 you have set up externals, but actual bundle doesn't based on ES6 imports/exports. They are necessary for tree shaking as said in the quote that you have brought:

It relies on the static structure of ES2015 module syntax, i.e. import and export.

Points of the issue that you have found:

• tree-shaking does not work if library built in commonjs
• rollup can build library into esm module (that are tree-shakable)
• unbuilt es modules imported from a library are tree-shakable

[ghost]

@davidyuk Is this still relevant for the v2 ?

[davidyuk]

This build process should be used in the current and future versions of the components package.

[edwarddikgale]

Guys I have looked at this pull request from a neutral. As mentioned by Denis, documentation at Vue recommends packaging components to be served by via npm taking advantage of rollup. Angular adopt a similar approach using angular material. There is also an article here that helps make sure we code to take advantage of tree-shakes: https://medium.com/@joanxie/utilize-webpacks-tree-shaking-in-your-vue-application-a0dc63c0dfac . I'm not in favor of Denis or Said but in favor of using rollup and serving components as a single npm package

[dadaphl]

I'm a bit confused, @edwarddikgale can you elaborate plase

... serving components as a single npm package ...

[ ] all components are in one single npm package [ ] each component will be published as a standalone npm package

[edwarddikgale]

Single package for all components

[sadiqevani]

@davidyuk Can you rebase develop here and then we merge?

[sadiqevani]

@davidyuk

This PR is a bit outdated! I propose either one of the following actions to be taken:

1. Rebase the develop branch on top of this branch, and fix the build process to it uses @vue/cli
2. Close this PR and create a new branch and migrate the build process to @vue/cli
3. Close this PR and continue using the same build process.

Now, in case you have time you can handle the rebasing, I don't have much context on this branch and it will take me a long time to deal with it.

On the other hand, if you're still willing to go with @vue/cli but you have no time, I'll create a feature branch and start working on it, but it might take a bit of time.

[davidyuk]

I don't have time to continue developing this feature. But this branch contains some stuff that can be useful for someone who will continue it.

Also, this PR is not only about @vue/cli but it uses rollup that can make this package actually tree shakable.