Add Jest like API

This PR add a new assertion API.

This is a proof of concept, not all planned features are implemented yet, the rest will come soon enough, so stop me if this is something you don't want.

Planned features

[x] (not.)identicalTo
[x] (not.)assignableTo
[x] (not.)subtypeOf
[x] toThrowError with code and/or message matching
[ ] (not.)toBeDeprecated
[ ] (not.)toBeInternal
[ ] toHaveDocBlock
[ ] toHaveDocBlockTag
[ ] print
[ ] some helpers like toBeNever, toBeNull, ...
[ ] ...

import {assertType} from 'tsd';

declare const fooString: string;
declare const fooNumber: number;

// Pass
assertType<string>().identicalTo<string>();
assertType<string>().identicalTo(fooString);
assertType(fooString).identicalTo<string>();
assertType(fooString).identicalTo(fooString);

assertType<string>().not.identicalTo<number>();

// Fail
assertType<string>().identicalTo<number>();
assertType<number>().identicalTo(fooString);
assertType(fooString).identicalTo<number>();
assertType(fooString).identicalTo(fooNumber);

assertType<string>().not.identicalTo<string>();

assertType<'foo'>().identicalTo<string>();
assertType<'foo'>().identicalTo(fooString);
assertType('foo').identicalTo<string>();
assertType('foo').identicalTo(fooString);

In addition to being more descriptive, decoupling the expected type from the type to be compared makes the bug #142 with generics disappear by design.
declare const inferrable: <T = 'foo'>() => T;

// Pass
assertType<'foo'>().identicalTo(inferrable());
assertType(inferrable()).identicalTo('foo');

// Fail
assertType<string>().identicalTo(inferrable());
assertType(inferrable()).identicalTo(fooString);

Add toThrowError
type Test<T extends number> = T;

// Pass
assertType<Test<string>>().toThrowError();
assertType<Test<string>>().toThrowError(2344);
assertType<Test<string>>().toThrowError('does not satisfy the constraint');
assertType<Test<string>>().toThrowError(/^Type 'string'/);

// Fail
assertType<Test<number>>().toThrowError();
assertType<Test<string>>().toThrowError(2244);
assertType<Test<string>>().toThrowError('poes not satisfy the constraint');
assertType<Test<string>>().toThrowError(/Type 'string'$/);

I'm personally not a big fan of the Jest API, but I'll leave that decision to Sam.

decoupling the expected type from the type to be compared makes the bug #142 with generics disappear by design.

How does the problem disappear by design? If it fixes that issue, that is a big benefit of this PR.

I think it does! Would this be a replacement for the existing API? Seems confusing to have two very different ways of using tsd, one of which can tell you everything's ok when it's not. I ask partly because it might be nice to align APIs with expect-type here too - assertType(...).identicalTo(...) is equivalent to expectTypeOf(...).toEqualTypeOf(...), and assertType(...).assignableTo(...) is equivalent to expectTypeOf(...).toMatchTypeOf(...).
Since there are some users of each it could be nice to give them the same API (some people might care more about CLI error messages who'd go for tsd vs others who might want it to "just work" by running tsc who'd go for expect-type).

I think it does! (since the Actual type is already baked-into assertType(), so by the time the generic for Expected comes into play in .identicalTo(), the compiler won't alter the inferred typearg based on the expectation)

That's right. The thing with the current design is that we share the same parameter to test two potentially different types and due to the nature of TS generic inference this can produce unexpected results with optional parameter. As we provide the expected type it will be propagated to parameters that are not defined in the target type.
declare const inferrable: <T = 'SomeDefaultValue'>() => T

function expectType<Expected>(expected: Expected): void {}

expectType<number>(inferrable()); // 'T' is inferred from 'Expected' => number
expectType(inferrable<number>()); // 'Expected' is inferred from 'T' => number
expectType(inferrable()); // Since no parameter was provided 'Expected' is inferred from 'T' default value => 'SomeDefaultValue'

By splitting the expected type and the actual type and ensuring that the user never produces a generic and an argument at the same time the bug no longer occurs.
assertType(foo).assignableTo(bar);
assertType(foo).assignableTo<Bar>();
assertType<Foo>().assignableTo(bar);
assertType<Foo>().assignableTo<Bar>();

assertType<Foo>(bar).assignableTo<Bar>(); // Error: Do not provide a generic type and an argument value at the same time.
assertType<Foo>().assignableTo(); // Error: A generic type or an argument value is required.

Would this be a replacement for the existing API? Seems confusing to have two very different ways of using tsd, one of which can tell you everything's ok when it's not.

This is a very good question. I think they can coexist without any problem for a while to allow a smooth transition. But that's a decision for @SamVerschueren to make (as long as he's happy with the new API).

I ask partly because it might be nice to align APIs with expect-type here too - assertType(...).identicalTo(...) is equivalent to expectTypeOf(...).toEqualTypeOf(...), and assertType(...).assignableTo(...) is equivalent to expectTypeOf(...).toMatchTypeOf(...).

I'm not convinced by this. The names of the methods are literally the names of the TS compiler and they do what they say they do. For example your toMatchTypeOf is rather a assignableTo or subtypeOf than assignableTo alone.


Mid

Codecov Report

Merging #45 (73e8c69) into main (54dac30) will decrease coverage by 10.12%.
The diff coverage is 22.87%.

@@             Coverage Diff             @@
##             main      #45       +/-   ##
===========================================
- Coverage   79.65%   69.53%   -10.13%
===========================================
  Files          13       13
  Lines         821      975      +154
===========================================
+ Hits          654      678       +24
- Misses        144      274      +130
  Partials       23       23

Impacted Files
Coverage Δ

middleware/middleware.go
0.00% <0.00%> (ø)

middleware/security.go
98.27% <ø> (ø)

server/server.go
37.03% <0.00%> (-4.21%)
:arrow_down:

errors/errors.go
82.05% <100.00%> (ø)

log/log.go
87.59% <100.00%> (+2.63%)
:arrow_up:

middleware/csrf.go
96.73% <100.00%> (ø)

middleware/log.go
91.35% <100.00%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 54dac30...73e8c69. Read the comment docs.


gitee is very slow

Xmake Version
N/A
Operating System Version and Architecture
N/A
Describe Bug
Running the install script fetches the dependencies as submodules from gitee (including ones where upstream is hosted elsewhere, so I guess these are mirrors?).  Unfortunately, this is painfully slow (outside China?) and often results in timeouts and disconnections.  I'm trying to set up CI to test the xmake builds each day to prevent regressions, but the most recent run has spent ten minutes trying to download the source.  Compiling it then takes <30s.
It would be great if the install script could provide an option to fetch from some mirror, rather than doing a clone from such a slow server.
Expected Behavior
Running the install script doesn't take over 10 minutes to fetch the code before it even starts building.
Project Configuration
N/A
Additional Information and Error Logs
N/A

why do not use xmake github action? it will be faster. and it support install binary cache.
https://github.com/xmake-io/github-action-setup-xmake

now it will use github url on action ci. https://github.com/xmake-io/xmake/commit/52548a1ba3a1949d3cf36d5c019a1849e3e45d17


Document Storybook release process

Issue: N/A
What I did
Document our release/decision-making process initially for discussion purposes, and finally as a reference so we have some standards about this for our releases.

Gathered/incorporated some feedback from this gist: https://gist.github.com/shilman/7993bc0c74974ef1ace7c4f96900554c
Extended it to incorporate the concept of blocking bugs as discussed with @tmeasday

How to test
N/A

@tmeasday thanks for catching the typos. added a bug filter to the issue search, but did not filter out issues that have a milestone because it's useful to see when things are scheduled among the results. can filter more later if things get too out of control.

LGTM! Might want to wait for a couple more approvals to this process change.

Looks good to me!


How can the [feature request] tree form be expanded and folded dynamically through JavaScript?

Existing Component
是
Component Name
el-table
Description
希望能够添加方法动态展开与折叠树形表格

Now, I can only use V-IF to force the refresh of subcomponents to dynamically expand and collapse the tree list.

How to use V-IF for that?

@moabtools
Define a reactive property, such as isExpanded.
Then force the table to render
this.isExpanded = false
this.$nextTick(() => this.isExpanded = true)