feat: initial changes to just compile with bun

[neoandmatrix]

Description

This PR introduces the changes to just compile and start the cli with bun with some modules removed namely asyncapi/parser and asyncapi/modelina as they were using the @spotlight package's spectral depedency which appears to be unsupported by bun. Also the fetching of examples is removed as it was dependent on parser.

The major issues as per my finding are with parser.

@Souvikns @Shurtu-gal @AayushSaini101 please have a look and any guidance will be helpful to me for next steps.

Thanks.

[changeset-bot]

⚠️ No Changeset found

Latest commit: b38888c

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[sonarqubecloud]

Quality Gate failed

Failed conditions
D Maintainability Rating on New Code (required ≥ A)

See analysis details on SonarQube Cloud

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE

[neoandmatrix]

Some more findings on this migration and what changes in my opinion are required for this to be achieved:-

1. Assessing the core compatibility of the oclif with bun if found that they officially mentioned that bun can be used as a runtime , at least in dev environments mentioned here.

2. As mentioned above using bun as a runtime is possible but using it as a package manager will require some changes as far as i have tried.

• The first challenge that needs to be overcome is in a core dependency used by oclif named plugin-plugins. While running bun install to migrate to bun for the package management it fails as following

and the pre-install script is "preinstall": ":; (node ./preinstall.js > /dev/null 2>&1 || true)".

In my opinion there can be 2 possible solutions for this : -

1. Open and issue in bun core repository for this and tackle this with them.

2. We can fork and modify plugin-plugins package form oclif to use some other package manager like npm and also the
   oclif to then use that package instead of official one. Maintenance will be an overhead in this approach. The reason is
   probably most likely due to bun currently not supporting yarn and only npm. This approach will need to be further
   discussed in detail.

• Then comes the second challenge of incompatibility of two other asyncapi packages asyncapi/parser and asyncapi/modelina which both use @spotlight packages which we might need to upgrade as the current versions used are almost 2 years old and hence don't support bun.

One more improvement for tests we can try is using the bun test runner which also might allow us to speed up tests as we are already using jest and this is also based on jest.

The advantages of migration to bun in my opinion and as per testing are:-

1. Significant speed up in the installation process of cli.
   The installation time significantly reduces with bun but not with others like pnpm as they still under the hood use nodejs and hence limited by it. pnpm is only faster if the dependencies are previously installed then only that helps in caching but with bun every install is significantly faster.

2. Faster file reads and writes. As cli needs to work a lot with files bun being significant faster in that can help to speed up that also. This is based on this benchmark https://lemire.me/blog/2024/03/12/how-to-read-files-quickly-in-javascript/ but can be tested with cli also if previous steps are successful.

3. Tests runtime will also improve as mentioned above.

4. Local development is also faster with bun as i tested with a fresh oclif project.

In my opinion these advantages of bun would not be available with other package mangers like pnpm which we were considering as under the hood they all still use nodejs as the runtime which will still be the bottleneck.

@Souvikns @Shurtu-gal @AayushSaini101 I would really appreciate your thoughts and views on this as that would help me to further move in the direction of this migration if it aligns with goals of the project and helps it. As this will require some effort and also if needed discussion with other projects maintainers would be really helpful to me if i can get some early advice on this as i am considering this to be part of goals that are to be achieved during Gsoc'25 and will help me to plan this properly.

Thanks.