Check the number of type parameters before handling the Range type

[todays-mitsui]

There is an issue where a user-defined Range type is incorrectly treated as std::ops::Range.
The behavior differs depending on whether the type has exactly one type parameter or not, but in either case, the user-defined Range is ignored.

Example: A panic occurs when there are no type parameters.

use tsify_next::Tsify;

#[derive(Tsify)]
pub struct Range {}

#[derive(Tsify)]
//       ^^^^^ error: proc-macro derive panicked
//             help: message: index out of bounds: the len is 0 but the index is 0
pub struct A {
    range: Range,
}

When the Range type is specified for a field in a struct, Tsify expects it to have one type parameter.
However, a user-defined Range type without type parameters causes a panic.

Example: When there is one type parameter, it is treated as std::ops::Range.

use tsify_next::Tsify;

#[derive(Tsify)]
pub struct Range<T> {
    _phantom: std::marker::PhantomData<T>,
}

#[derive(Tsify)]
pub struct A {
    range: Range<()>,
}

Generated .d.ts file:

export interface Range {}

export interface A {
    range: { start: null; end: null };
    // Expected: `range: Range;`
}

This issue arises because the system cannot correctly determine whether Range refers to a user-defined type or std::ops::Range.
Unfortunately, avoiding this issue when there is exactly one type parameter seems difficult.
On the other hand, for cases with a different number of type parameters, the distinction is straightforward. Clearly, Range or Range<T, U> should not be interpreted as std::ops::Range.

Adding a guard to TsType::from_name() to handle cases with exactly one type parameter may provide a solution to this problem.

[siefkenj]

Hmm. Looks like the expandtest tests are failing. Possibly because they are using a newer rust version than when they were last run...would you mind rebuilding those with MACROTEST=overwrite cargo test?

[todays-mitsui]

I ran MACROTEST=overwrite cargo test and committed the changes in the tests/expand/ directory.
ee02def

I also ran ./test.sh locally, and it seems that all the tests passed.

[siefkenj]

Very weird. There are new tests failing. Do they fail on your system?

[todays-mitsui]

Looking at the workflow logs, it seems the test is failing during the execution of wasm-pack test --node.
On my local environment, this test passed without issues.

I tried a solution in the forked repository.
It appears that the default version of Node on ubuntu-latest is v18.20.5, which seems outdated.
By upgrading the Node version to 20, wasm-pack test --node passes successfully.

[todays-mitsui]

Oops, it seems the e2e test is still failing even after upgrading the Node version.
This fix looks straightforward—perhaps a mistake caused some spaces in the snapshot to be removed?

I'll create a Pull Request to address this workflow issue.

[todays-mitsui]

I have created a Pull Request to fix the workflow. Please review it.

• Fix CI errors #47

Once the workflow completes without errors, it should be easier to review and accept this Pull Request.

[siefkenj]

Thanks for this! And thank you for adding tests right from the start :-D