Bring back dependabot

[ferferga]

This PRs brings back dependabot, which was removed by #110 (by mistake, I think? Kindly explain the reasoning if I'm wrong @MrTimscampi)

Dependabot handle updates for dependencies of this client (TypeScript and axios), not the client itself. Dependencies bundled by the generator are hardcoded by OpenApi generator and not "updated" automatically by it. For example, the generator had no updates since April 2019 until January 2020 (to fix a major security vulnerability), which is way too much time without updates (which also included minor security fixes, also important.

package.json is also completely ignored by the generator and it's only manipulated by CI. This is required so the package works properly in ES6, as the default tsconfig was also not correct.

[ThibaultNocchi]

Just a question, what does happen when stable is updated between npm releases?

[ferferga]

This repo doesn't push anything to npm by itself, we need to manually trigger it (at least until we verify it's stable and we have the server and web CI fully migrated to Actions).

The updated dependencies will be pushed with the next publishing to npm registry, but a dependency update alone doesn't make/push a new version.

We could likely change that and add a hash or something like we do with unstable, so dependencies are more deterministic.

[ThibaultNocchi]

I was more thinking in the line of "the npm stable doesn't have the same dependencies than the stable git dir". Is it important that the package.json from git stable/ will diverge from the one in npm?

[heyhippari]

I removed it for a few reasons:

• openapi-generator will re-generate the package.json every time, leading to it being overwritten (since the workflow overwrites everything and makes a new commit)
• since the version is synced between the server and the stable release, updates will be useless, as they can't be pushed (due to an existing version already being published)
• it generates noise for essentially no benefit (You can pass an axios instance to the constructor for the API classes, so in essence, the dependency doesn't mean anything, as it's only used when not providing an instance)
• axios updates can lead to client breakages, if openapi-generator doesn't account for potential changes

With these in mind, it seemed better and more future-proof to let version pinning occur in openapi-generator instead of in this repository.

[ThibaultNocchi]

since the version is synced between the server and the stable release, updates will be useless, as they can't be pushed (due to an existing version already being published)

yup that's what I was thinking with my previous answer