Jonas Kello

It seems the quick-fix for `prefer-immutable-types` is not working as in `perfer-readonly-type`. We use this quick-fix a lot to save typing the readonly stuff by hand.  

Given this code: ```ts interface Foo { readonly bar: string; } function testtwo(quantity: string): ReadonlyArray { return [{ bar: "" }]; } ``` and this config: ```js module.exports = {...

Would setting `ReadonlyDeep` on global level give the exact same enforcement as `prefer-readonly-types` in all places? Currently I'm getting "6559 problems" when switching to `prefer-immutable-types` in the code base I'm...

Regarding the quick-fix, for us it would be enough that it fixes the same cases as `prefer-readonly-types` did. Perhaps we can detect if the current config allows for a simple...

This code: ```ts export type Program = Generator; function partialCall4( ...args: [...TProgramArray] ): ExtractProgramArrayReturnTypeTuple { return args as any; } type ExtractProgramArrayReturnTypeTuple = { [K in keyof T]: T[K] extends...

I agree this is very confusing. I have been trying to create a child span for a long time now without any success. At least my attempted child spans to...

Thanks for the clarification. I guess the reason this change was made is because having explicit parents does not work with automated tracing. You can pass down parent within your...

This is a rather small change but a total blocker for using node16/nodenext module resolution in typescript. There is no workaround as according to the typescript team this should be...

Yes this check should be removed now then. I think we could consider it a bug that it is still there so it could be released quickly in a patch...

In my case I ended up using a single namespace for the tenant and two `kustomiztion.yaml` files with different `nameprefix` setting for the two deployments of the same app. Both...