Unknown keys on instance should not be typed as `any` when instantiating from `Base.defaults()` or `Base.plugin()`

[gr2m]

Example

const base = new Base()

// TS complains as expected
base.unknown

const BaseWithDefaults = Base.defaults({})
const baseWithDefaults = new BaseWithDefaults

// TS does _not_ complain, `.unknown` is typed as `any`, and it shouldn't
baseWithDefaults.unknown

The problems are these two lines from the resulting .d.ts file

javascript-plugin-architecture-with-typescript-definitions/index.d.ts

Line 22 in 3e0da09

[x: string]: any;

javascript-plugin-architecture-with-typescript-definitions/index.d.ts

Line 28 in 3e0da09

[x: string]: any;

I don't quite understand whey they are coming from, and how I can change them to at least [x: string]: unknown.

Any idea?

Here is a playground with the full source code

[Andarist]

Can you drop the generic contraint S extends Constructor<any>? I don't quite see why you need it there - you shouldn't be able to parameterize it but rather the base class should flows/compose through layers of .defaults() calls etc. Or am I missing something?

Without it works:
TS playground (with some extra casting in the static plugin method)

[gr2m]

Thanks a lot for looking into it!

Can you drop the generic contraint S extends Constructor<any>?

It came from here:
https://stackoverflow.com/questions/58636914/chaining-static-plugin-class-method-to-extend-instance-apis-multiple-times/58706699#58706699

With your changes, Base.plugin(myPlugin).defaults(options) no longer works. This test is now failing

javascript-plugin-architecture-with-typescript-definitions/test.ts

Lines 53 to 68 in 3e0da09

	it(".plugin().defaults()", () => {
	const BaseWithPluginAndDefaults = Base.plugin(fooPlugin).defaults({
	baz: "daz",
	});
	const BaseWithDefaultsAndPlugin = Base.defaults({
	baz: "daz",
	}).plugin(fooPlugin);
	const instance1 = new BaseWithPluginAndDefaults();
	const instance2 = new BaseWithDefaultsAndPlugin();
	expect(instance1.foo()).toEqual("foo");
	expect(instance1.options).toStrictEqual({ baz: "daz" });
	expect(instance2.foo()).toEqual("foo");
	expect(instance2.options).toStrictEqual({ baz: "daz" });
	});

TS Playground to showcase the problem

[Andarist]

Oh, I thought that TS would be smart enough to understand that this type should infer from creates subclasses 😬

Casting return values with typeof this somewhat works but I guess this might also be incorrect for some other reason:
TS playground

[gr2m]

Thanks, that works with my tests so far. I'll ship it in @octokit, we'll see how it goes!

[Andarist]

Ping me if you encounter any problems - quite frankly this API was somewhat hard to grok at first for me and I was unsure what are exact constraints that you want to achieve so it's hard for me to assess if this will truly "just work" for everything you want to achieve.

I'm not entirely sure why this was the problem but I think this was because you were using mixin types/feature (I was not aware that TS supported this~ up to this point) and that using those triggered some different code path in TS that resulted in this. My "fix" just works around this by not using those mixin semantics and just implementing "mixin" by hand at the type-level.

[github-actions]

🎉 This issue has been resolved in version 2.0.3 🎉

The release is available on:

• GitHub release
• npm package (@latest dist-tag)

Your semantic-release bot 📦🚀