To handle all special types in options and result.

What if user want to return the branches directly?

That means we need special wrap types for each special types for this purposes, but they can still be treated as special type branches inside the code.

for testing:

type R = number | undefined

testType.hasUndefined<R>(true)

TS now has Awaited<T>

It appears to be quite easy to extend the implementation of GreaterThan to also support negative numbers, which would make it significantly more useful.

Here's my rough implementation, including the fix from #161.

The devDependency @unional/devpkg-node was updated from 1.1.3 to 1.1.4.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

@unional/devpkg-node is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

To remove:

• First (FindFirst, ArrayPlus.Find)
• isType.t() (isType(), testType.true())
• isType.f() (isType(), testType.false())
• isType.never() (isType(), testType.never())
• isType.equal() (testType.equal())
• CommonKeys (CommonPropKeys)
• PadLeft (PadStart)

Newly deprecated:

• drop() (no replacement)
• Concat (ArrayPlus.Concat)

Using the latest version of type-plus (3.4.0) I'm seeing the following type errors:

I don't know if it's by design, but both IsTuple and IsArray return false for never[] in the latest version of type-plus.

TypeScript might have do something special for X<T, Then, Else> inference.

Need to investigate this

Currently this is not possible because TypeScript does not support infer generic declaration:

const newType = {
  toNative: <T>(value: T) => Generate<T['value']>
}

function createChecker(...newTypes: Specs) {
  return {
    satisfy<T>(type: T, subject: unknown): Generate<Specs, T> { ... }
  }
}

Inside Generate<>, it cannot pass the T to the toNative() when we found which type can handles T.

the type checking types will support various options like distribute, exact.

Need to see how to support these options without breaking the inference.

Also, may add IsXXX<T, $O, $Else = never> for backward compatibility before completely dropping the <T, Then, Else> support.

NumericStruct.Add<NumericStruct.FromNumeric<A, Fail>, NumericStruct.FromNumeric<B, Fail>>
//              ^ fail as input not accepting `Fail`

Instead of:

type NumericStruct.Add<A extends NumericStruct, B extends NumericStruct> ...

Accept Maybe<NumericStruct> and propagate the error.

This will simplify many implementation.

Update to support Options: { caseNever, caseArray, caseEmptyTuple, caseUpperBound, caseLowerBound }

The type definition of the infer type generated by TypeScript has error.

Making consumer of this package need to do skipLibCheck to get pass compilation.

currently, testType.* can be used in test directly. e.g.:

it('blah', () => {
  testType.equal<A, B>(true)
}

However, when the tests get complicates or when there are may duplication, you would like to extract part of the test and reuse it:

it('blah', () => {
  testMyType(...)
}

it('bruh', () => {
  testMyType(...)
}

testMyType(...) {
  testType....
}

Since testType.* are 💥 immediate, they can't be used this way.

Not sure if there is a way to achieve this a the library level as this is crossing the type-value boundary (i.e. fail type throws Error)

each builder.with() should be isolated from each other,
so that it can do this:

const b = stub.builder(...)
const x = b.with(...)
const y = b.with(...)

const a = x.create()
const b = y.create()

Equal<A, B, T = A, E = never>
NotEqual<A, B, T = A, E = never>

Changing Equal<> is not a problem and is clear, as A and B are equal, returning either one is fine.

NotEqual<> is more problematic as It's ambiguous on which one to return.
Returning A per "convention" helps, but the logic is not clean.

There are probably use cases for this, as the filter variant is more generic than the predicate variant.

Will keep it as is for now, until there are sufficient use cases to support the change.

This will be a breaking change.

Forgive me if I have understood wrong (the functionality) but the following code shouldn't work without compiler problems?

assertType.isTrue(true as CanAssign<any, number>);

If the order is inverted, it works fine. Also, the following code apparently compiles:

let a: any = 4;
let b: number = a;

let d: number = 3;
let e: any = d;

StackBlitz print:

Thank you :)

Something like:

import { pluginA } from 'plugin-a'
import { pluginB } from 'plugin-b'
const checker = T.createChecker(pluginA, pluginB)

const subject: unknown = { ... }
checker.check(pluginA.create(...), subject)

The plugin needs to supply a type guard function, and the type.

It might not be possible as generic on generic is not possible.

like ArrayPlus.Find etc.

https://auth0.com/blog/typescript-3-exploring-tuples-the-unknown-type/#:~:text=Optional%20Tuple%20Elements&text=Notice%20that%20the%20length%20of,stated%20in%20the%20TypeScript%20release.

  type Foo = { a?: string, b: string }
  const koo: Pick<Foo, 'a'> = {} // error, koo: { a: string | undefined }

Not sure if there is a way to detect the optional flag of the property.

/cc @dragomirtitian to see if you have an idea.

The devDependency @size-limit/preset-small-lib was updated from 2.2.2 to 2.2.3.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

@size-limit/preset-small-lib is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

Currently T.union.create(T.boolean) will get { type, value, any, true, false, create, optional, ... } from T.boolean.
It would be great if we can simplify it to only { type, value } as other type information are just noise.

We can do it for one value:
Value -> Pick<Value, 'type' | 'value'>

Need a way to map Pick over array and objects.

I wasn't aware that testType had a canAssign (the documentation apparently didn't mention it yet).

Um, thanks for pointing it out. I thought I have the doc updated. Seems like I have missed it.

Originally posted by @unional in #349 (comment)

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• chore(deps): update dependency turbo to v1.13.2
• chore(deps): update pnpm to v8.15.7
• chore(deps): update dependency eslint-plugin-yml to ~1.14.0
• chore(deps): update dependency @size-limit/esbuild-why to v11
• chore(deps): update dependency @size-limit/preset-small-lib to v11
• chore(deps): update dependency @types/node to v20
• chore(deps): update dependency eslint to v9
• chore(deps): update dependency size-limit to v11
• chore(deps): update github/codeql-action action to v3
• chore(deps): update pnpm to v9
• Click on this checkbox to rebase all open PRs at once

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

The devDependency assertron was updated from 7.0.2 to 7.1.0.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

assertron is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

The filter vs validate types are useful only if not modified.
Also it promotes bad usage as the If<Condition, Then, Else> enclosed type logic can lead to infinite result due to the lack of actual conditional type support.

It's better to return ThenType and ElseType and then Foo<...> extends infer R? R extends ThenType ? ... : ... etc.

The syntax and implementation still needs some clean up.

But the general direction should be good.

All types should follow Foo<...inputs, Options>: R signature.

I devised a fast logarithmic string length algorithm based on carefully building string type patterns which is surprisingly tedious due to ${string}${string} simplifying to ${string} so we need to add an extra character $ before and after during all of our checks.

Anyways, this string length algorithm supports getting the length of strings up to 10,000 characters long (uses tuples for math). However, you could add an alternate path after the cache gets to 2^13 (8,192) to use your arbitrary math type to support more strings up until a very large size due to beauty of the logarithmic scale.

type TCache = [string, 0[]];

type StringLengthUp<
  T extends string,
  $Acc extends 0[] = [],
  $Cache extends TCache[] = [[`$${string}`, [0]]],
> =
  //
  $Cache extends [infer C extends TCache, ...infer $RestCache extends TCache[]]
    ? (
      `${C[0]}${C[0]}_` extends `$${string}$${infer $After}`
        ? `${C[0]}${$After}` extends `${infer $Before}_` ? $Before : never
        : never
    ) extends infer $DoubleC extends string
      ? `$${T}` extends `${$DoubleC}${infer $Rest}` ? StringLengthUp<
          $Rest,
          [...$Acc, ...C[1], ...C[1]],
          [[$DoubleC, [...C[1], ...C[1]]], ...$Cache]
        >
      : `$${T}` extends `${C[0]}${infer $Rest}`
        ? StringLengthUp<$Rest, [...$Acc, ...C[1]], $Cache>
      : StringLengthDown<T, $Acc, $RestCache>
    : never
    : $Acc["length"];

type StringLengthDown<
  T extends string,
  $Acc extends 0[],
  $Cache extends TCache[],
> = $Cache extends
  [infer C extends TCache, ...infer $RestCache extends TCache[]]
  ? `$${T}` extends `${C[0]}${infer $Rest}`
    ? StringLengthDown<$Rest, [...$Acc, ...C[1]], $Cache>
  : StringLengthDown<T, $Acc, $RestCache>
  : $Acc["length"];

type StringLength<T extends string> = T extends "" ? 0 : StringLengthUp<T>;

type String9999 = "<a 9999 character long string>";
type String9999Length = StringLength<String9999>; // 9999

The code is quite ugly so there still might be some opportunities for simplification.

And the docs for IsNegative is incorrect.

Here is another implementation of Equal that almost work.

Keeping it here for reference:

	BothNever<
		A,
		B,
		Then,
		Else,
		BothAny<
			A,
			B,
			Then,
			Else,
			And<
				IsSymbol<A>,
				IsSymbol<B>,
				Then,
				And<
					IsObject<A>,
					IsObject<B>,
					And<
						IsFunction<A>,
						IsFunction<B>,
						[A, B] extends [B, A] ? Then : Else,
						Properties<A> extends infer PA
							? Properties<B> extends infer PB
								? (<_>() => _ extends (PA & _) | _ ? 1 : 2) extends <_>() => _ extends (PB & _) | _ ? 1 : 2
									? [PA, PB] extends [A, B]
										? Then
										: Else
									: Else
								: never
							: never
					>,
					[A, B] extends [B, A] ? Then : Else
				>
			>
		>
	>

The devDependency @types/jest was updated from 24.0.1 to 24.0.2.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

@types/jest is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

Added StrictArrayType for the current behavior.

The ArrayType should accept both array and tuple like StringType accept string and string literals.

Added LooseArrayType for the time being, before the breaking change.

There seems to be an issue with the GreaterThan implementation, so it is wrong for certain combinations of numbers (but none of the numbers tested in the .spec.ts file).

Example (TS Playground):

import { GreaterThan } from "type-plus";

type test1 = GreaterThan<10, 19> // Correct (false)
type test2 = GreaterThan<19, 10> // Incorrect (returns false but should be true)

The issue seems to be in the implementation of OnDigitArray, which as far as I can tell should just look like this:

type OnDigitArray<DA extends number[], DB extends number[]> = (
  Equal<Head<DA>, Head<DB>> extends true
    ? OnDigitArray<Tail<DA>, Tail<DB>>
    : Digit.GreaterThan<Head<DA>, Head<DB>>
)