Replace stampit with TypeScript mixins #3481

char0n · 2023-11-30T16:09:45Z

The goal of this issue is to determine if it make sense to switch from stamps to mixins. If it is determined that we're going to do that, another issue should be created to track the implementation progress there.

Pragmatically it just make sense to be able to use advanced TypeScript 5 features like decorators. Let's push through with this on OpenAPI 2.0 namespace, and see where we'll get.

TODO:

Documentation changes

Resources:

char0n · 2024-01-04T13:05:16Z

Additional notes:

After further research I've come into the conclusion (subjective one), that It's currently really not worth the effort. If we would like to switch to TypeScript mixins we would have to rewrite significant amount of code and we'd still would have to use some kind of abstraction like ts-mixer to provide convenient API.

We would replace one way of doing things (IMHO more flexible with stamps) with another one, which is less flexible.

char0n · 2024-01-04T13:18:23Z

Thinking further...what we can do is to identify packages where using stamps is not really necessary. We really only need stamps for facilitating multiple inheritance which is not natively supported by JavaScript/TypeScript Classes - we use stamps mostly in namespace packages = packages that starts with apidom-ns-*

So for example this package: https://github.com/swagger-api/apidom/tree/main/packages/apidom-parser could be transformed to TypeScript Classes (with proper visibility).

It will create a breaking change as instead of const parser = ApiDOMParser(); we'll have to do const parser = new ApiDOMParser(); but it's still acceptable as we're in pre-release mode

We can even avoid the breaking change by utilizing the pattern for instantiating a class without a new keyword.

Refs #3481

char0n · 2024-01-10T07:55:49Z

Another package that has been identified is https://github.com/swagger-api/apidom/tree/main/packages/apidom-ast

All the AST node types can be represented as TypeScript classes as there isn't multiple inheritance involved.

glowcloud · 2024-01-10T08:47:41Z

The packages that I've been working on:

I'll make the suggested changes from #3646 to Parser and to the other packages, as some cases will apply there as well. The Adapter packages should be ready for a PR then. After that, I'll continue the work on the AST package.

I believe that these packages can be changed as well:

Refs #3481

* refactor(parser-adapter-yaml-1-2): change from stamps to classes Refs #3481 * refactor(parser-adapter-yaml-1-2): apply ordering convention * refactor(parser-adapter-yaml-1-2): apply requested changes * refactor: change to readonly and arrow functions * refactor(parser-adapter-yaml-1-2): change the order of fields --------- Co-authored-by: Vladimír Gorej <vladimir.gorej@gmail.com>

Refs #3481

glowcloud · 2024-01-16T13:35:29Z

Status update for each of the previously mentioned packages:

Changes merged into main:

Changes waiting for a PR review:

https://github.com/swagger-api/apidom/tree/main/packages/apidom-ast - refactor(ast): change from stamps to TypeScript classes #3681

Currently in progress:

https://github.com/swagger-api/apidom/tree/main/packages/apidom-core

To change:

Co-authored-by: Vladimír Gorej <vladimir.gorej@gmail.com> Refs #3481

Refs #3481

…ses (#4103) Refs #3481 BREAKING CHANGE: all strategies from apidom-reference package became a class and requires to be instantiated with new operator.

Refs #3481 BREAKING CHANGE: all strategies from apidom-reference package became a class

…t classes (#4104) Refs #3481 BREAKING CHANGE: all visitors from apidom-reference package became a class and requires to be instantiated with new operator.

Refs #3481

Refs #3481 BREAKING CHANGE: IdentityManager from apidom-core package became a class and requires to be instantiated with new operator.

Refs #3481 BREAKING CHANGE: File from apidom-reference package became a class and requires to be instantiated with new operator.

Refs #3481 BREAKING CHANGE: Reference from apidom-reference package became a class and requires to be instantiated with new operator.

…4100) Refs #3481 BREAKING CHANGE: ReferenceSet from apidom-reference package became a class and requires to be instantiated with new operator.

…4101) Refs #3481 BREAKING CHANGE: resolvers from apidom-reference package became a classes and requires to be instantiated with new operator.

) Refs #3481 BREAKING CHANGE: parsers from apidom-reference package became a class and requires to be instantiated with new operator.

…ses (#4103) Refs #3481 BREAKING CHANGE: all strategies from apidom-reference package became a class and requires to be instantiated with new operator.

…t classes (#4104) Refs #3481 BREAKING CHANGE: all visitors from apidom-reference package became a class and requires to be instantiated with new operator.

Refs #3481

char0n · 2024-05-14T08:52:35Z

Finalized in #4105