Webpack for server apps

[nickvergessen]

Ref #7933 (comment)

@nextcloud/javascript How can I make sure this uses the version we load from the updatenotification/js/vue.js instead of the version from e.g. mail?

Or how do we handle this, when there are multiple different versions on one instance because of multiple apps?

[nickvergessen]

The thing with webpack is, that we either:

• commit the built artifacts => bad for diff/conflicting PRs/bisect
• dont commit the artifacts => bad for developers because default doesnt work without running npm and stuff

[tcitworld]

If the build process is simple enough (make assets), I don't mind running this before having a working NC dev installation.

[juliusknorr]

I would still prefer to have a common vue version for the server part. @ChristophWurst Is there any method using webpack to just bundle vue itself and have it exported at a different namespace, maybe something like OC.Lib.Vue ? So we have a shipped one that doesn't interfere with the ones that apps might ship. And we would need to run that build step only for bumping the vue version.

I also thought about using vue for the app settings page, which would be a huge improvement to have a clean javascript code there.

[juliusknorr]

If the build process is simple enough (make assets), I don't mind running this before having a working NC dev installation.

We had that discussion with the SCSS introduction as well. Mostly against having a build process for js/scss in the server component: #1786

[tcitworld]

I've read this discussion before. However, building assets for a project is pretty common these days (and we do it for some apps), I don't think it should be regarded as a blocking point, even more if we can tell something like "assets are not build" in the dev env.

[nickvergessen]

@tcitworld well same for composer to get php dependencies.
Still until I had to run the mail app, I did not have npm installed. I'm a php developer and just want to make a simple php patch. What do I need npm for on my machine?
It's just one additional burden and exactly where this is coming from. Frontend people dont want to run composer, backend people dont want to run npm/bower/...

[MorrisJobke]

The problem I see with a shipped Vue: it is super hard to update and we keep an old version for ages, because a ton of code depends on it :/ (like your jQuery and jQuery migrate and jQuery UI)

[tcitworld]

@nickvergessen There's solutions like mouf/nodejs-installer (or the reverse) which can be wrapped inside a make command for instance.

I see the point here, but at least please tell me that shipping build files isn't an option ;)

[ChristophWurst]

@ChristophWurst Is there any method using webpack to just bundle vue itself and have it exported at a different namespace, maybe something like OC.Lib.Vue ? So we have a shipped one that doesn't interfere with the ones that apps might ship.

This is only true if you assume a single app being loaded on a page. If you have multiple apps (e.g. on the settings page) that load their Vue (or any other identical lib that pollutes the global namespace) you get the very same problems.

IMO server and apps should have separate libs. Sharing them like we do now just makes app dev pain as you're bound to outdated libraries shipped by the server. Additionally, we are totally limited in updating the libraries in server, as the update might randomly break apps as mentioned by @MorrisJobke.