Release automation

[juliusknorr]

It would be nice to have the changeling generation and npm releases handled through GitHub actions or at least have some docs on which steps to take. This showed up to be an issue when trying to release @nextcloud/moment but is the same for other npm packages we have in our organisation. Only @nextcloud/vue seems to be automated/documented currently.

[skjnldsv]

Same for apps releases on https://github.com/nextcloud-releases/

[vinicius73]

I took the liberty of creating a gist to track all our NPM Packages.

https://gist.github.com/vinicius73/555d739de02a431fc8a2a33aa4e5cb69

The idea is to improve every package with better docs and a standard release process.

For the build process

• Use rollup instead of babel
  • CommonJS is the default target
  • EcmaScript Modules
• TypeScript to generate ES5 code compliance.
  • TS is able to generate ES5 code.
  • We do not need to use a lot of transpiring processes.
  • According to our actual browserlist (>0.25%, not ie 11, not op_mini all, not dead, Firefox ESR) All browsers who we support is compatible with the major features of ES2015+
  • The only one with issues will be Android Browser 4.4.3-4.4.4, but Since Android 5, the Android webview went evergreen, and has chrome as the default browser
    • Actually, Nextcloud Android App requires Android 6.0 and up
    • Nextcloud Talk Android App requires Android 5.0 and up

About ESM

ESM (EcmaScript Modules) are largely compatible with node and browsers.

It allows tree shaking and modern tooling like Vite, Skypack and Parcel.

It is a big step of JavaScript ecosystem and there are some incompatibilities between CJS and ESM but we can handle it using rollup and adjusting our package.json and release process.

"main": "dist/index.js",
"module": "dist/index.esm.js",
"types": "dist/index.d.ts",
"exports": {
  "import": "./dist/index.esm.js",
  "require": "./dist/index.js"
},
"files": [
  "dist/"
],

It keeps every old-style package manager, node version, and bundler working without any issue.

About Docs

It is very important to make sure we have a good doc with good references about some parts of Nextcloud usage and development.

Packages with poor README.md files must be revised to make them better.

About NPM and GPR

Nowadays we have NPM and GPR (Github Package Registry) as public options to store and distribute javascripr packages.

The idea is improving the security and resilience of the JS ecosystem.
All major npm front-ends (NPM, Yarn, pnpm) are able to use not only other registries, also github repos directly.

Also, we can publish in gitlab too.

[vinicius73]

Related PR who I've already sent about this.

• Automate release process nextcloud-libraries/nextcloud-event-bus#490
• Bundle improvements nextcloud-libraries/nextcloud-event-bus#481
• Bundle improvements nextcloud-libraries/nextcloud-initial-state#412
• Bundle improvements nextcloud-libraries/nextcloud-axios#438
• Bundle improvements nextcloud-libraries/nextcloud-auth#408

[skjnldsv]

I created a nice config with typescript, esm, esnext, vue for rollup in https://github.com/nextcloud/nextcloud-upload/blob/master/rollup.config.js
Thank you for the help @vinicius73, your configs helped me understand a bit better the process.

Feel free to take inspiration on this. It works great and also generates typings.

[skjnldsv]

@susnux I guess we could all move to the vite config?
We should document the requirements here for the final ticket:

• Mandatory data in package.json
• Mandatory config files
• Vite ecosystem recommendations (e.g. vitest)...

[susnux]

Not sure how that is related? Yes I would recommend to use vite for bundling and recommend our shared config - also to get some feedback on how to improve there.

But not sure how this is connected to automated releases?

[skjnldsv]

In my head that was: unifying the config will help having the same release process
But you're right, this could be two very distinct steps 🙈