chore: Make dependencies external

[juliusknorr]

Before:

✓ 282 modules transformed.
dist/style.css 0.21 KiB / gzip: 0.15 KiB
dist/main.js 717.44 KiB / gzip: 203.73 KiB
dist/main.js.map 1937.99 KiB

After:

✓ 15 modules transformed.
dist/style.css 0.21 KiB / gzip: 0.15 KiB
dist/main.js 37.21 KiB / gzip: 7.25 KiB
dist/main.js.map 136.01 KiB

For nextcloud/server#36384

[ChristophWurst]

😎

[susnux]

This is not a good idea as long as we use webpack for applications!

Because you set the dependency to external¹ webpack now has to treeshake and it is quite bad doing it.
In numbers, a simple app just consisting of the example code in the readme:

With this: 9543055 Bytes ~ 9,1 MiB
When keeping the default import: 2674259 Bytes ~ 2,55 MiB

¹: The testapp output size, when keep changing the import but not setting @nextcloud/vue to external, is - thanks to better tree shaking of vite on this library - 4139035 Bytes ~ 4MiB.

EDIT: I just want to clarity that the size I wrote above is the whole js directory including the source map (du -bs js/)

[juliusknorr]

Thanks for that insight @susnux I think this is really bad for app that use more components and we should rather consider moving everything to importing the default export of the lib instead of the dist folder. As far as my tests went the dist imports are not tree-shakable at all.

There is probably no optimal way (except from moving away from web pack to site), but the index.module.js of @nextcloud/vue is currently at 883K which seems to be a value that a lot of apps and also server easily exceed with the individual modules from dist.

Just out of curiosity, du you have the small test app in some repo? I'd be curious to see the actual impact in the bundles with webpack-bundle-analyzer or vite-bundle-visualizer

[Pytal]

Seems like a good idea to let vite do the tree-shaking here then?

[susnux]

I think this is really bad for app that use more components and we should rather consider moving everything to importing the default export of the lib instead of the dist folder. As far as my tests went the dist imports are not tree-shakable at all.

I tried this for the forms app (just js files):
dist import: 9.694 MiB (main branch)
default: 13.524 MiB (feat/move-to-module-import branch)

I think for dist import only the really required parts are included while importing from default export might include some parts which are not flagged side effects free, like the emoji mart is always included (about 1MiB), e.g. compare:

`dist` import:

default import:

Just out of curiosity, du you have the small test app in some repo? I'd be curious to see the actual impact in the bundles with webpack-bundle-analyzer or vite-bundle-visualizer

No but it is not hard to create, see below:

Simply create a new project, install @nextcloud/password-confirmation (use this branch) and @nextcloud/webpack-vue-config.
Create a file src/main.js with this content:

import { confirmPassword } from '@nextcloud/password-confirmation'
import '@nextcloud/password-confirmation/dist/style.css' // Required for dialog styles

export const foo = async () => {
    try {
        await confirmPassword()
        // Your logic
    } catch (error) {
        // Your error handling logic
    }
}

and webpack.js with

const path = require('path')
const webpackConfig = require('@nextcloud/webpack-vue-config')

module.exports = webpackConfig

[juliusknorr]

Thanks for the insights. I reverted the import changes for now and just added the packages as external.

Switching the imports would still be good for larger apps that include more components anyways, but lets's keep this separate for now.

[susnux]

I think this will work better when the vue components are provided as a esm package. Then even webpack can treeshake it more efficient.

Switching the imports would still be good for larger apps

yes for all apps that e.g. include the emoji mart (one of the biggest dependencies), like the text app or the collectives app, this will be much better.