Split providers from this package

[nichtich]

The sdk is also used independently from Cocoda so another name may be a better fit. Renaming is a breaking change and parts of this module may still have focus on Cocoda, so how about:

• create a new package jskos-providers with providers (that's the main part of this package)
• keep lib/CocodaSDK.js in this package

Only breaking change may be renaming CDKError to JSKOSProviderError but adding the latter as subclass of the former and superclass of specific error classes may also work.

[stefandesu]

I think it makes sense to split it off (we've talked about it in the past), but I'm not sure I understand what you are suggesting. I feel like there are three components:

• lib/CocodaSDK.js - basically a way of making it a little easier to use multiple registries that use different providers, also offering methods to aggregate results for multiple registries like getSchemes; this depends on both providers and error classes
• Providers - there's a BaseProvider that all other providers depend on, and for each API and type of entity, there's a different provider; these also use the error classes
• Error classes used by both of the above

There are also utilities which are only used in the providers.

So I think what you are suggesting (and what makes a lot of sense) is this:

• Put providers and error classes into the new jskos-providers package.
• Remove those from this package, then have cocoda-sdk (still named this?) depend on jskos-providers, offering the exact same functionality as before.

Is my understanding correct?

I feel like we need a new major release anyway for certain things related to JSKOS API 2.0, so we can also add a breaking change to the error classes.

If tree-shaking can be used with jskos-providers, it doesn't matter much that it contains all existing providers, I think. Otherwise it would also be possible to offer certain providers as a completely separate package.

[nichtich]

Is my understanding correct?

Yes. cocoda-sdk should be usable as before.

If tree-shaking can be used with jskos-providers, it doesn't matter much that it contains all existing providers, I think.

I'm not sure which to go:

1. jskos-providers including everything with growing list of dependencies for new providers
2. jskos-providers as core and multiple packages such as jskos-provider-sparql for individual providers
3. Same as 2 but have a mono-repository in git, published in form of multiple npm packages

Although tree-shaking is possible, I'd prefer packages with less dependencies (but maybe we don't need that many additional dependencies anyway). Variant 3 seems best in theory but requires additional setup complexity.

[stefandesu]

I agree that variant 3 seems like the best. In this case, a monorepo pushlished as multiple separate packages makes a lot of sense to me.