Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Write Tests #28

Open
Hookyns opened this issue Feb 11, 2022 · 0 comments
Open

Write Tests #28

Hookyns opened this issue Feb 11, 2022 · 0 comments
Labels
enhancement New feature or request good first issue Good for newcomers help wanted Extra attention is needed in-progress
Milestone

Comments

@Hookyns
Copy link
Owner

Hookyns commented Feb 11, 2022

Write tests, at least for core features before v1.0.0.

@Hookyns Hookyns added enhancement New feature or request help wanted Extra attention is needed good first issue Good for newcomers labels Feb 11, 2022
@Hookyns Hookyns added this to the v1.0.0-alpha milestone Feb 11, 2022
Hookyns added a commit that referenced this issue Feb 13, 2022
### Added
- `getType(val: any)` it is possible to get type of runtime value,

<dl>
<dd>

```typescript
const someValue: unknown = new Animal();
getType(someValue); // > Type<Animal>
```
This works mainly with classes.
Before #29 is implemented, `@reflect()` decorator, `@reflect` JSDoc tag or `getType<OfThatType>()` is required or there will be no Type metadata.

Native types such as Object `{ foo: "", bar: 5 }`, Array `[ {}, true, 5 ]` and primitive types are supported too; those types are recognized and their properties are parsed at runtime.

*Getters and setter of Objects are recognized.*
\
*Classes without metadata will be parsed as Objects.*

</dd>
</dl>

- `Decorator.getArguments(): Array<any>` - constant literal arguments of decorators are captured,
- `Type.isPrimitive()`,
- partial test coverage (~75%) - issue #28,
- `TypeBuilder`,
- decorator can be CallExpression`@decorator()` or (new) just Identifier `@decorator`
- implementation of #7 - custom Property and Method decorators supporting `getType<T>()` of generic parameters, like already supported class decorators.

### Changed
- JSDoc tags @reflectGeneric and @reflectDecorator removed in favor of single @reflect,
- `Property.decorators` changed to `Property.getDecorators()` - to keep it same as `Type.getDecorators()` and `Method.getDecorators()`,
- `Type.flattenInheritedMembers()` support base union and intersection types,
- fixed issue #27,
- fix of some circular dependencies in runtime package,
- few other small bug fixes.
Hookyns added a commit that referenced this issue Feb 14, 2022
New tests (#28) - coverage ~88 %.

Changed
- Changed way of handling types of runtime value.
Now there is SomeClass.prototype[REFLECTED_TYPE_ID] = ID of SomeClass's type; generated for each class in the project (not just those decorated via @reflect). It does not mean that metadata of those classes will be generated. Logic of generating type's metadata is still the same, use getType<SomeClass>() somewhere, apply @reflect decorator or apply any other decorator tagged by @reflect JSDoc tag.
This is preparation for include/exclude configuration (issue #29).
- custom decorators tagged by @reflect JSDoc tag does not have to have generic parameter
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request good first issue Good for newcomers help wanted Extra attention is needed in-progress
Projects
None yet
Development

No branches or pull requests

1 participant