Server: Webpack for server apps

[nickvergessen]

Ref https://github.com/nextcloud/server/pull/7933#discussion_r162316115

@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.

[juliushaertl]

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.

[juliushaertl]

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: https://github.com/nextcloud/server/issues/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.

[go2sh]

In the end you can't have all: No build dependencies, no global libraries and no checked in build artifacts.

I would vote adding build dependencies and use something like yarn, which massively speeds up the build process. Although I understand that this is really annoying for backend developers.

[skjnldsv]

@jancborchardt will love this discussion :)
The previous decision iirc was to not increase the level entry and to not to implement a make function! :)

[go2sh]

I mean, you definitely could create some crazy php logic (like the js concat and scss pre stuff) to insert libraries into some local namespaces. Makes debugging harder, but you don't need a make function and a low entry level. But the performance of not precompiled components will hurt some time, especially if some thing like the settings get updated.

[rullzer]

The conclusion was to check in build artifacts. So closing this.