feat: add Cypress

[aeworxet]

This PR introduces for ./apps/studio-next:

• Cypress with testing minimal set of web application's UI elements due to upcoming migration to ./apps/design-system (skeleton of the UI testing that will need to be reviewed after migration)

  • GUI testing is invoked with npm run cy:open
  • Headless end-to-end testing for different browsers is invoked with npm run cy:e2e:* (refer to the cy:e2e:* part of package.json for a list of available browsers (edge is reserved for Windows machines))

  

• API route http://localhost:3001/api/v1/generate that only returns requests, just as a proof of concept that the server side is functioning (works only in a local dev environment; the deployed version is subject to CORS restrictions)

Deployment to Vercel is successful and can be viewed at https://asyncapi-studio-studio-next.vercel.app

Related to #661
Related to #1101

[changeset-bot]

⚠️ No Changeset found

Latest commit: 97fc975

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

[netlify]

✅ Deploy Preview for modest-rosalind-098b67 ready!

Name	Link
🔨 Latest commit	97fc975
🔍 Latest deploy log	https://app.netlify.com/sites/modest-rosalind-098b67/deploys/66ea01016254430008573954
😎 Deploy Preview	https://deploy-preview-1094--modest-rosalind-098b67.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[netlify]

✅ Deploy Preview for asyncapi-studio-design-system ready!

Name	Link
🔨 Latest commit	97fc975
🔍 Latest deploy log	https://app.netlify.com/sites/asyncapi-studio-design-system/deploys/66ea01019a75210007577d87
😎 Deploy Preview	https://deploy-preview-1094--asyncapi-studio-design-system.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[netlify]

✅ Deploy Preview for studio-next ready!

Name	Link
🔨 Latest commit	97fc975
🔍 Latest deploy log	https://app.netlify.com/sites/studio-next/deploys/66ea0101be0c9c00080c8465
😎 Deploy Preview	https://deploy-preview-1094--studio-next.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[aeworxet]

@Amzani @KhudaDad414
@asyncapi/bounty_team

[aeworxet]

I started with the addition of Cypress so I could spot regressions during migration to CodeMirror.
Comparison with PR #1062

@Amzani
A couple of questions:

• Is there a design file (Figma maybe?) where I can take unique names for all HTML elements from, so testing frameworks could find them in the webpage (same as I gave the name data-testid="button-settings" to the Settings button?)
• What names should I give to HTML elements' data-* attributes: data-testid, data-test, or data-cy?
• Should there be a separate spec file for components' testing, or, in the case of Studio, only full flow (e2e) makes sense?

[Amzani]

@aeworxet

Is there a design file (Figma maybe?) where I can take unique names for all HTML elements from, so testing frameworks could find them in the webpage (same as I gave the name data-testid="button-settings" to the Settings button?)

Not for the existing studio, we only have one for the new improvements that will be integrated once we finish the NextJS migration: https://www.figma.com/proto/bPMB3lkMTOOMuKk0oGLuNm/Studio?type=design&node-id=96-2392&scaling=contain&page-id=0%3A1&starting-point-node-id=2%3A2

What names should I give to HTML elements' data-* attributes: data-testid, data-test, or data-cy?

I vote for data-test for simplicity and in case we want to switch to an other testing tool in the future.

Should there be a separate spec file for components' testing, or, in the case of Studio, only full flow (e2e) makes sense?

The goal is regression test, so I would suggest full flow (e2e), we can encourage components testing for new feature we add to the project.

@KhudaDad414 WDY?

[Amzani]

I would remove CodeMirror Integration from the scope of this issue for now, until we merge everything.

[aeworxet]

I'm working on code generation for Studio, and after POST request to https://api.asyncapi.com/v1/generate I get

Version 3.0.0 is not supported.
Please use latest version of the specification.

Code, responsible for this is
https://github.com/asyncapi/parser-js/blob/master/src/ruleset/functions/isAsyncAPIDocument.ts#L25
https://github.com/asyncapi/parser-js/blob/master/src/constants.ts#L22
and the file which is searched for for 3.0.0 HAS it in master:
https://github.com/asyncapi/spec-json-schemas/blob/master/index.d.ts#L12

It needs to be checked on the server what version of ./node_modules/@asyncapi/specs/index.d.ts it contains.
@smoya

[Amzani]

@aeworxet we should remove the dependency with https://github.com/asyncapi/server-api in the NextJS version of studio as this repository might be deprecated soon.

So the idea is to directly use the generator library.

Not all of them supports V3, AFAIK the following supports V3

• https://github.com/asyncapi/nodejs-template/
• https://github.com/asyncapi/html-template
• https://github.com/asyncapi/markdown-template

If < V3 all the generators should work as expected.

[smoya]

So the idea is to directly use the generator library.

@Amzani would you mind linking to where that decission has been made? Just to be in sync with asyncapi/server-api#576 where the idea, afaik, was to keep a server but the code living in CLI repo.

[Amzani]

@smoya I was assuming that if only Studio uses this API there is no need to maintain it anymore thus deprecating the server-api repo and not migrate it to CLI to reduce complexity.

[aeworxet]

So the idea is to directly use the generator library.

@Amzani

@KhudaDad414 suggests the opposite, to stick with server-api.
So which one should it be?

Should I invest time into rewriting the logic for SSR, or should I just bugfix the current approach?

(#1094 (comment) is still relevant then)

[KhudaDad414]

@aeworxet IMHO it makes sense to bug fix the current code base. By that I mean sticking to the server-api approach.

As Fran said in the original issue, migration is already hard enough, trying to implement new features at the same time would quadruple the complexity.

[aeworxet]

@KhudaDad414
'Code Generation' functionality still requires checking of the ./node_modules/@asyncapi/specs/index.d.ts version on api.asyncapi.com as per #1094 (comment) since it is the server that is returning the error.

[KhudaDad414]

@aeworxet Since you get the error on the current Studio as well, I would consider resolving it to be out of scope for this Bounty Issue.

We can have another issue and discuss it over there.

[aeworxet]

I'm investigating options for deployment of Studio to a Docker container, and the possibility that the server part might become completely independent, up to being hosted fully in a CLI with invocation through asyncapi server start, led me to a question if deployment of Studio to a Docker container as a full Next.js app (with API Routes, SSR, and others) is needed at all.

The most runtime-dynamic part of Studio currently is the generation of templates, and it can be done through a POST request to an API from a static website (it is made this way currently, in fact.)

I'm not sure OG preview generation is a mandatory functionality for a containerized Studio, it can be left reserved for https://studio.asyncapi.com

I have deployed to https://asyncapi-studio-studio-next.vercel.app a build of Studio with output: 'export' (explanation what 'export' build is, features that are NOT supported.)

The whole 'export' build is nine (9) Mb, it has First Contentful Paint 0.4 s (+ better overall performance score in Lighthouse,) and it doesn't seem to lack any functionality.

Should this version of Studio's build be used for a Docker container?

[Amzani]

The most runtime-dynamic part of Studio currently is the generation of templates, and it can be done through a POST request to an API from a static website (it is made this way currently, in fact.)

We want to enable long term features like authentication for instance. generation of templates using API to POST should be something we could migrate IMO as we don't want to maintain an entire repository just for 1 single POST /generate method instead of using directly the generator library.

Should this version of Studio's build be used for a Docker container?

How complex is having everything in Docker image?

[aeworxet]

@Amzani

How complex is having everything in Docker image?

It is supposed to be straightforward but I ran into an error on a command that executes fine on desktop, so I'm investigating it.

[aeworxet]

@KhudaDad414
How should I handle these ESLint's issues? They are not mine, but should I rewrite them anyway, disable ESLint rules, or should these simply be ignored due to future rewrite?

./src/components/Navigation.tsx
88:17  Warning: Refactor this function to reduce its Cognitive Complexity from 16 to the 15 allowed.  sonarjs/cognitive-complexity

./src/components/Navigationv3.tsx
159:17  Warning: Refactor this function to reduce its Cognitive Complexity from 18 to the 15 allowed.  sonarjs/cognitive-complexity

./src/components/common/Switch.tsx
14:27  Error: 'e' is defined but never used.  @typescript-eslint/no-unused-vars

[KhudaDad414]

@aeworxet they should be ignored.
we are already ignoring them in sonar.
https://github.com/asyncapi/studio/blob/master/.sonarcloud.properties

[aeworxet]

Disabled ESLint's rules on warnings and the error.

[aeworxet]

SonarCloud is frozen.

Sergio was dealing with this issue several days ago
asyncapi/parser-js#1008 (comment)

[aeworxet]

Can this PR be merged, or is there anything else that needs to be done on it?

[Amzani]

@aeworxet could you fix the conflict ?
Thanks

[aeworxet]

@Amzani
Fixed.

[aeworxet]

I had to rename

ConvertVersion -> AsyncAPIConvertVersion

which was renamed recently in @asyncapi/converter v1.5.0.

In the change's PR only the name was changed, so all functionality is supposed to remain the same, but pinging @jonaslagoni just in case.

[Amzani]

LGTM

[aeworxet]

@KhudaDad414
Can you please dismiss your change request since I have removed all Docker-related code?

[sonarcloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[KhudaDad414]

/rtm