feat: Simple API to test new api against current service

[richtera]

feat: Add simple API change for create method to accept partial serviceConf

Allow passing in serviceConf which has either a set of connections or { id?: Principal, url: URL }.
If the principal is not provided construct a did:web: from the hostname.

[hannahhoward]

Pasting @richtera 's rationale here for reviewers:

Hi, I created a little PR which lets you pass a partial serviceConf structure with just { access: { url } } for example so it's easy to test the new API against the old service. You can pass the id or a whole connection as well. https://github.com/storacha/upload-service/pull/254 I am planning to use this so I don't have to do a regexp replace and can include and hoist it as a normal node module. Unfortunately LIT is using both multiformats 9.9.0 and 11.0.2 but yours is clean now with 13.3.2 through the whole package hierarchy!!! Great!

[hannahhoward]

This seems like a reasonable change for making the services simpler to custom configure.

LGTM but want to double check with @alanshaw or maybe @fforbeck .

Does ServiceConf still need to exists? Having two different types seems confusing.

[alanshaw]

CI is failing because you updated Lit dependencies but did not update the lockfile.

[alanshaw]

Might make this a bit easier to understand:

Suggested change

	/** @type {(options: Partial<import('./types.js').ServiceConfOptions>) => import('./types.js').ServiceConf} */
	/**
	* @param {Partial<import('./types.js').ServiceConfOptions>} [options]
	* @returns {import('./types.js').ServiceConf}
	*/

[richtera]

Ok will check my changes, rebase to upstream and fix this. I am compiling a slightly newer branch, which has changed I didn't want to release yet.

[alanshaw]

Since this is a type specifically for options, perhaps the properties should be defined as optional (?) rather than using Partial everywhere.

[richtera]

That's a good idea.

[alanshaw]

Importing import('./types.js').Principal is circular - just import Principal from the existing @ucanto/interface import and use it here.

[alanshaw]

Does ServiceConf still need to exists? Having two different types seems confusing.

It needs to exist due to the different services the client talks to and us wanting to be able to change it for dev/testing purposes.

The access, upload and filecoin connections all point to the same service currently. The gateway config points to freeway. I appreciate that it is mildly confusing that 3 of these point to the same service.

Personally I'd like to keep the separation in code so that they can become different later if needs be, but I don't mind condensing the 3 to 1 until that time if you feel strongly about it.

[richtera]

Does ServiceConf still need to exists? Having two different types seems confusing.

It needs to exist due to the different services the client talks to and us wanting to be able to change it for dev/testing purposes.

The access, upload and filecoin connections all point to the same service currently. The gateway config points to freeway. I appreciate that it is mildly confusing that 3 of these point to the same service.

Personally I'd like to keep the separation in code so that they can become different later if needs be, but I don't mind condensing the 3 to 1 until that time if you feel strongly about it.

I guess it's possible to make a variant type. The external configuration only needs the url most of the time and not a lot of the other properties. But it's very much a subjective thing for sure. I tried to not touch the original ServiceConf, because it has properties the rest of the code requires.