Publish pre-builds for each weclapp version instead of a generator

[JanHolger]

What problem does this feature solve?

Well nobody can use this without building a custom version of the client to their own source, versioning becomes really hard and this approach is a really bad idea in general. Why don't you just make a single sdk, that takes the weclapp url and token and uses axios (or a similar wrapper but axios is industry standard) so it's cross-platform and doesn't require different builds for different targets?

What does the proposed API look like?

Make the api configurable instead of hardcoding it into the sdk. Publish the actual built sdk to npm, not the generator.

[simonwep]

Well nobody can use this without building a custom version.

This is the reason why this is a generator, some may use a pre-release system that comes with a different API. This generator tries to be as flexible as possible.

Versioning becomes really hard.

If weclapp updates it's API (this may include breaking changes in some cases) you have to make adjustments to your implementation either way, building the SDK helps you identify breaking changes immediately. The generator is not compatible with weclapp in particular, but the OpenAPIv3 spec so if the openapi.json from weclapp changes, the SDK will build a different version.

This approach is a really bad idea in general.

From a convenience perspective maybe, but how exactly? It allows you to identify breaking changes immediately and work with different systems without having to find / install the correct sdk. And we (currently) have too many changes / systems we work with that we can build a SDK for each individual version. We may be doing that if we publish a new major version of the API though.

Why don't you just make a single sdk, that takes the weclapp url and token and uses axios (or a similar wrapper but axios is industry standard) [...]

I don't understand what you mean here, this is what it already does. It takes a URL and a token and uses fetch (an actual standard and not a library like axios that just takes up space) to fetch the openapi.json to generate the SDK. In some cases you need a node build, in some cases a browser build if you're using a reverse-proxy. And RxJS if you're working with (older versions of) Angular.

[...] so it's cross-platform and doesn't require different builds for different targets?

It uses node that is cross-platform and requires different builds because not everyone has the same setup. (There are still differences between node and the browser if you use it there).

Make the api configurable instead of hardcoding it into the sdk. Publish the actual built sdk to npm, not the generator.

That would be substantially more expensive right now for us than just building the locale version of whatever weclapp version you're currently targeting. There are many changes introduced right now in our API and publishing a version for each pre-release and nightly versions would be total overhead. We simply do not have the resources / see no reason in this.

[simonwep]

After all, this was originally an internal tool that we thought would be helpful to publish since the old connect package is very much out-dated and in really bad shape. You can still use the openapi.json to build / generate your own SDK. But even then, if a new weclapp version comes out you have to do something. And updating the sdk-generator and running it is as good as updating the pre-bundled dependency, and undoubtedly better than finding out if your code is affected from breaking changes.