srleecode / domain Goto Github PK

Just question.
I currently use your package for DDD in my libs package of my application, and it is marvellous.

I was wondering - can DDD be used in an module federation application remote? Should it be used?

Thanks

My attempt to generate srleecode schematic items always gives an errror

Executing task: ng generate @srleecode/domain:appGroupingFolder --name=xom --no-interactive --dry-run <

Cannot find module '@srleecode/domain/shared/utils'
Require stack:

• /home/stclair/__/@workspace/pim/node_modules/.pnpm/@srleecode[email protected]/node_modules/@srleecode/domain/generators/grouping-folder/create-app/src/lib/shared/initialise-workspace.js
• /home/stclair/__/@workspace/pim/node_modules/.pnpm/@srleecode[email protected]/node_modules/@srleecode/domain/generators/grouping-folder/create-app/src/generator.js
• /home/stclair/__/@workspace/pim/node_modules/.pnpm/@nrwl[email protected]/node_modules/@nrwl/tao/src/shared/workspace.js
• /home/stclair/__/@workspace/pim/node_modules/.pnpm/@nrwl[email protected]/node_modules/@nrwl/tao/src/commands/generate.js
• /home/stclair/__/@workspace/pim/node_modules/.pnpm/@nrwl[email protected]/node_modules/@nrwl/tao/index.js
• /home/stclair/__/@workspace/pim/node_modules/.pnpm/@nrwl[email protected]/node_modules/@nrwl/cli/lib/init-local.js
• /home/stclair//@workspace/pim/node_modules/.pnpm/@nrwl[email protected]/node_modules/@nrwl/cli/bin/nx.js
  The terminal process "/usr/bin/bash '-l', '-c', '/home/stclair//@workspace/pim/node_modules/.bin/ng generate @srleecode/domain:appGroupingFolder --name=xom --no-interactive --dry-run', 'ng generate @srleecode/domain:appGroupingFolder --name=xom --no-interactive --dry-run'" failed to launch (exit code: 1).

Terminal will be reused by tasks, press any key to close it.

Any reason as to why this is occurring?

Note: https://angular.io/guide/angular-package-format#exports

> Executing task: yarn nx generate @srleecode/domain:ngApplicationLayer --groupingFolder=sphinny --no-interactive --dry-run <

Package subpath './src/generators/library/library' is not defined by "exports" in /Users/ben/SnyderDev/snyder/snyder-apps/node_modules/@nrwl/angular/package.json
The terminal process "zsh '-c', 'yarn nx generate @srleecode/domain:ngApplicationLayer --groupingFolder=sphinny --no-interactive --dry-run'" terminated with exit code: 1.

Terminal will be reused by tasks, press any key to close it.

> Executing task: yarn nx generate @srleecode/domain:ngApplicationLayer --groupingFolder=sphinny --buildable --no-interactive --dry-run <

Package subpath './src/generators/library/library' is not defined by "exports" in /Users/ben/SnyderDev/snyder/snyder-apps/node_modules/@nrwl/angular/package.json
The terminal process "zsh '-c', 'yarn nx generate @srleecode/domain:ngApplicationLayer --groupingFolder=sphinny --buildable --no-interactive --dry-run'" terminated with exit code: 1.

Terminal will be reused by tasks, press any key to close it.

> Executing task: yarn nx generate @srleecode/domain:appGroupingFolder --name=sphinyy --no-interactive --dry-run <

Package subpath './src/generators/init/init' is not defined by "exports" in /Users/ben/SnyderDev/snyder/snyder-apps/node_modules/@nrwl/angular/package.json
The terminal process "zsh '-c', 'yarn nx generate @srleecode/domain:appGroupingFolder --name=sphinyy --no-interactive --dry-run'" terminated with exit code: 1.

Terminal will be reused by tasks, press any key to close it.

Running into this on #30

Mocking services to get the correct state desired in the stories can be difficult. Instead of doing this, it would be easier to setup an interceptor that can mock the endpoint responses. This ticket is to investigate creating an interceptor for mocking the service calls when testing. This interceptor would be used in the application layer.

Can you provide an example app please?

I have the following hierarchy as shown in the screenshot.

I am trying to import the domain-layer TFrequency model into the presentation-layer frequency.component. However, the model is not being imported. The screenshot below shows that the Webstorm IDE sees the model....

The IDE says it cannot build a module path to the model.

NB: I had corrected the duplicated errors I mentioned in my previous Issue by searching for the errors with case-sensitivity on and replaced the duplications. So I don't know if that did something.

Also, please take below at s snippet from my root eslintrc.json and see if there is somthing wrong with the scoping of scope:ng-clerk-shared.

The tree structure of libs/ng-clerk/** is shown below:

The libs 'root-scope' share directory is shown below:

The intent of the libs/ng-clerk/share is to share its contents with libs/ng-history and libs/ng-examination ONLY.

Thanks

Investigate using cdk test harness with: https://github.com/jscutlery/test-utils instead of generating the component command with https://github.com/srlee309/component-command-utils.

Issues with the test harness that I think should be resolved first are:

• slow test suite load time jscutlery/devkit#6
• test harness are hard to write and use. They also don't allow getting test harnesses for sub components in a test harness jscutlery/devkit#5

Create a new generator for creating a component store. This can be used as a base https://github.com/ngrx/platform/tree/master/modules/schematics/src/component-store

Requirement:

• Right clicking a shell or feature component folder should give an option to create a new component store.
• It would create the component store service in the application library
• It would provide that component store service in the component
• It should throw an error if there is not an existing application library

Build is failing after running this migration script:

"version": "13.8.5-beta.1",
"description": "Renames @nrwl/node:package to @nrwl/js:tsc",
"factory": "./src/migrations/update-13-8-5/update-package-to-tsc",

For this issue, it needs to be determined what the best approach is for publishing multiple libraries as a single package. Suggestions so far seem to point to needing to have all libraries being published.

Will relook at this when there are updates on the below issue: nrwl/nx#4620

As there is no easy way to call the nx console with defaults, the input values needs to be provided, e.g. grouping folder. Passing in the wrong grouping folder can cause errors. It would be good to add warnings if the grouping folder passed in does not exist.

The E2E projects are across multiple domains , but there is often a need to have a common plugins file.
It should be able to take an option for this plugin file and include it in all the E2E projects.

I have a libs/ng-shared/shared/domain and libs/ng-shared/shared-dx domains. directives in shared-dx depend on types in shared. Is this allowed? Although compilation occur, the nx build always fail.

Is it possible to extract the TID into its own libs/ng-shared/ domain?

Below is a screenshot of the relationship

The below are options that you can pass to the nx library schematic, but aren't in this projects schematics yet.

"routing": {
  "type": "boolean",
  "default": false,
  "description": "Add router configuration. See lazy for more information."
},
"lazy": {
  "type": "boolean",
  "default": false,
  "description": "Add RouterModule.forChild when set to true, and a simple array of routes when set to false."
},

I am thinking:

• setting routing to true would add the routing and lazy flags as true to the shell library being created
• lazy would not be shown as an option
• An error would thrown if this option is true and a shell library is not being created

This plugin is missing the Nx version and Github Stars on the Nx Plugin Registry. To fix this, you need to publish a new version of the plugin that includes:

(1) @nx/devkit as a dependency (or peerDependency) and
(2) a repository.url in the package.json that points to this repo. i.e.

{
  "repository": {
    "type": "git",
    "url": "https://github.com/nrwl/nx.git",
    "directory": "packages/web"
  }
}

Thanks,
Isaac (Nx Team

Hello @srleecode - I have a large enterprise project ongoing; we were thinking to either enhance this plugin or fork and modify for our needs for the enterprise project. It will be ongoing for years -- a rewrite of a large company's ecosystem.

I was thinking to add another library type called kernel that is akin to feature (angular frontend component) but uses @nrwl/nestjs schematics. Is this something you want to include in this plugin -- and work together on it?

You can DM me; we could potentially addd you into our corporate project to assist with the DDD design and to enhance this plugin.

All ideas welcomed..

With @nrwl/workspace:move jest-config projects aren't getting removed.
Add rule to remove these projects from the jest config

Congrats on a very good offering on something that is gaining some momentum.

Reading around the topic I see where two other distinct categories are proffered/used/recommended by some:

• api: Provides functionalities exposed to other domains
• domain: Domain logic like calculations, validations or facades for use cases and state management. .

Given the five categories currently offered by your package...:
• feature: Implements a use case with smart components
• data-access: Implements data accesses, e.g. via HTTP or WebSockets
• ui: Provides use case-agnostic and thus reusable components (dumb components)
• util: Provides helper functions
• shell: provide and entry point for multiple domain apps

...I am not seeing where to consistently put the api and domain categories.

In your five categories, where would you place the api and domain categories described above?

Please let me know what you think.

Cheers

Add .nxignore with storybook files excluded when creating a domain

Investigate building and running the stories based on the affected projects with the ct target. Using a global storybook config it could have a function to add the affected story files.

• https://storybook.js.org/docs/angular/configure/overview#configure-story-loading
• https://medium.com/front-end-weekly/creating-a-storybook-instance-including-stories-from-multiple-libraries-in-a-nrwl-nx-workspace-89009a2bddf7

Store buildable, strict, enableIvy and publishable options when creating a domain.

Use these stored values automatically when adding new libraries to an existing domain..

I am thinking it would store these values when creating a domain in a json file name .domain.config.json with the project name as the key. Something like

{
  'application-domain': {
    'buildable': true,
    'strict': true,
    'enableIvy': false, 
    'publishable': true
  }
}

Moving or deleting a domain should update these config file.

In #9 I want to add a file domain.conf.json that would have the library build options used when creating a domain these would be reused when adding new libraries to that domain. It would be good to be able to generate this domain.conf.json from scratch for situations where domains have already been created before using this library or before the change in #9

The cypress domain tests should be updated to include:
https://www.npmjs.com/package/@testing-library/cypress

There should be an option for the domain test type so that you can choose component tests. This would use localhost:4400 as the base url. Component tests would run on a storybook instance that is running at localhost:4400

Add retries: 3 to the cypress.json files that are generated.

Add schematics so that you can add ngrx to a domain.

At the moment, I am investigating if this will be done by just using the vscode extension to:

• run a ngrx schematic https://ngrx.io/guide/schematics/store by clicking on the data-access library and selecting the desired schematic
• prefilling the appropriate values in the schematic opened in nx console

A schematic would only be created in this library if something extra or different from the ngrx schematics was needed.

As discussed in #4, there are some use cases where it would make sense for some things to be private in a domain ,i.e. only allowed to be used inside the domain.

Having a domain level api will lead to bundle size issues. Therefore, the approach taken will be to allow private apis to be created at the library level. I think the majority of the time these wouldn't be needed. This ticket will include the following changes:

New schematic that:

• Adds index private-api.ts
• Adds ts config path like normal path except private is before the library name, e.g. @project/test-application/test-domain/private/data-access
• Update vscode extension to allow adding private api by right clicking on library folder

The below is an option that you can pass to the nx library schematic, but isn't in this projects schematics yet.

"publishable": {
      "type": "boolean",
      "default": false,
      "description": "Generate a publishable library."
    },

I am thinking:

• setting this to true would mean that enableIvy should be false. A warning will be shown if publishable and enableIvy are both true
• In the domain schematic, if this is true it would mean that it was true for all the library schematics that get run
• When creating the domain, the publishable option value used would be stored and automatically reused when adding libraries to the domain. It would not be shown as an option in the addLibrary schematic.

Context

After adding files in the domain folder, they then often need to be included in the index.ts so that the other libraries can use them.

Requirement

• When right clicking on a libraries index.ts, there should be an option update barrel. This would export everything for all of the relevant files in the library. It should not include files like those under the mocks folder.
• When right clicking on the domain libraries testing.ts file, there should be an option update barrel. This would export everything for all of the files in the mocks folder.

The below are options that you can pass to the nx library schematic, but aren't in this projects schematics yet.

    "buildable": {
      "type": "boolean",
      "default": false,
      "description": "Generate a buildable library."
    },
  "strict": {
      "type": "boolean",
      "description": "Creates a library with stricter type checking and build optimization options.",
      "default": false
    },
 "enableIvy": {
      "description": "Enable Ivy for library in tsconfig.lib.prod.json. Should not be used with publishable libraries.",
      "type": "boolean",
      "default": false
    }

I am thinking these would all be preferences in the vscode extension that are set to true by default. If these options are true they will be passed as flags to all the nx library schematics that are run.

Hi
Is there a migration script that provides a path to angular 17.x.x?

I am asking because I attempt migration of my nx-monrepo project with a reference to this library as shown below:

  UPDATE package.json
---------------------------------------------------------
    Skipping migration for project medsoft-e2e. Unable to determine 'tsconfig.json' file in workspace config.
    Skipping migration for project registration-e2e. Unable to determine 'tsconfig.json' file in workspace config.
    Skipping migration for project ng-registration-registration-application. Unable to determine 'tsconfig.json' file in workspace config.
    Skipping migration for project ng-registration-registration-domain. Unable to determine 'tsconfig.json' file in workspace config.
    Skipping migration for project ng-registration-registration-infrastructure. Unable to determine 'tsconfig.json' file in workspace config.
    Skipping migration for project ng-registration-registration-presentation. Unable to determine 'tsconfig.json' file in workspace config.
    Skipping migration for project ng-shared-shared-application. Unable to determine 'tsconfig.json' file in workspace config.
    Skipping migration for project ng-shared-shared-domain. Unable to determine 'tsconfig.json' file in workspace config.
    Skipping migration for project ng-shared-shared-infrastructure. Unable to determine 'tsconfig.json' file in workspace config.
    Skipping migration for project ng-shared-shared-presentation. Unable to determine 'tsconfig.json' file in workspace config.
    Skipping migration for project ng-shared-shared-util. Unable to determine 'tsconfig.json' file in workspace config.
    Skipping migration for project ng-shared-shared-dx-domain. Unable to determine 'tsconfig.json' file in workspace config.
    Skipping migration for project ng-shared-shared-dx-presentation. Unable to determine 'tsconfig.json' file in workspace config.
    Skipping migration for project ng-shared-shared-dx-util. Unable to determine 'tsconfig.json' file in workspace config.
    Skipping migration for project ng-shared-shared-global-application. Unable to determine 'tsconfig.json' file in workspace config.
    Skipping migration for project ng-shared-shared-global-domain. Unable to determine 'tsconfig.json' file in workspace config.
    Skipping migration for project ng-shared-shared-global-presentation. Unable to determine 'tsconfig.json' file in workspace config.
    Skipping migration for project ng-shared-shared-global-util. Unable to determine 'tsconfig.json' file in workspace config.

My attempt at migration failed, so I am just trying to see if the relevant libraries have seen the migration errors.

Thanks

I created a domain:appGroupingFolder and examined my eslintrc.json. The relevant snippet is shown below:

{
  "sourceTag": "domain:core",
  "onlyDependOnLibsWithTags": [
    "domain:core",
    "domain:shared"
  ],
  "notDependOnLibsWithTags": []
},
{
  "sourceTag": "domain:registrati
  "onlyDependOnLibsWithTags": [
    "domain:registration",
    "domain:shared"
  ],
  "notDependOnLibsWithTags": []
},
{
  "sourceTag": "type:shell",
  "onlyDependOnLibsWithTags": [
    "type:application",
    "type:directive",
    "type:domain",
    "type:feature",
    "type:shell",
    "type:ui",
    "type:util"
  ],
  "notDependOnLibsWithTags": []
},
{
  "sourceTag": "type:feature",
  "onlyDependOnLibsWithTags": [
    "type:application",
    "type:directive",
    "type:domain",
    "type:feature",
    "type:shell",
    "type:ui",
    "type:util"
  ],
  "notDependOnLibsWithTags": []
},
{
  "sourceTag": "type:ui",
  "onlyDependOnLibsWithTags": [
    "type:application",
    "type:directive",
    "type:domain",
    "type:feature",
    "type:shell",
    "type:ui",
    "type:util"
  ],
  "notDependOnLibsWithTags": []
},
{
  "sourceTag": "type:directive",
  "onlyDependOnLibsWithTags": [
    "type:application",
    "type:domain",
    "type:directive",
    "type:util"
  ],
  "notDependOnLibsWithTags": []
},
{
  "sourceTag": "type:application"
  "onlyDependOnLibsWithTags": [
    "type:application",
    "type:data-access",
    "type:domain",
    "type:util"
  ],
  "notDependOnLibsWithTags": []
},
{
  "sourceTag": "type:domain",
  "onlyDependOnLibsWithTags": [
    "type:domain"
  ],
  "notDependOnLibsWithTags": []
},
{
  "sourceTag": "type:data-access"
  "onlyDependOnLibsWithTags": [
    "type:data-access",
    "type:domain",
    "type:util"
  ],
  "notDependOnLibsWithTags": []
},
{
  "sourceTag": "type:util",
  "onlyDependOnLibsWithTags": [
    "type:domain",
    "type:util"
  ],
  "notDependOnLibsWithTags": []
}
            ]
          }
        ]
      }

1. Given that that the shell, feature and ui tags all have the same 'onlyDependsOnLibsWithTags' how will I prevent circular references between thise tags?
2. Is there a recommendation for the inheritance structure? For eg feature -> ui -> domain -> util?
3. Is it sufficient for me to remove the tags that I don't want from the 'onlyDependsOnLibsWithTags'? Or do I have to put the remove tag in the 'notDependsOnLibsWithTags'

Add https://www.npmjs.com/package/nx-stylelint

Add the style-lint task to the generated components and directives

Options:

• application: string
• domain: string
• library: string
• component: string
• stories: string[]
• createTestComponents: boolean // whether or not to add the stories in a single .stories.ts file or a stories folder with a .stories file and test components for each story
• addArgs: boolean

If stories already exist for the component they will be added to the existing stories.
Title would be like ${application}/${domain}/${component}

At the moment, the cypress projects are in the folders .cypress (for e2e) and .storybook, but the storybook spec and support files are also in .cypress. This leads to the affected just picking up the e2e project instead of both the e2e and storybook project. For better affected with the cypress projects, it might be a good idea to do the following:

• move the storybook integration files and related cypress files into .storybook
• create a new library under the folder .cypress-selectors this would be depended on and used by the e2e and storybook projects

There are a few scenarios where the references aren't being updated. These should be fixed.
• Move doesn’t update the testing import path
• Move/Delete doesn’t update eslintrc.
• Nx json tags aren’t updated when moving domain

Investigate creating a schematic to add a component to a domain.

Schematic options would be:

• domain name
• component name
• changeDetection type. Based on this the component would be created in either the ui if it was OnPush or feature library if it was not.

Trying to create a shell. Using the presentation layer does not offer me any option to create a shell.

I am using the current release of the library.

The task executed is shown below:

Executing task in folder xom: pnpm exec nx generate @srleecode/domain:ngDomainLayer --groupingFolder=libs/ng-clerk/shared/ --addJestJunitReporter=true --buildable=true --enableIvy=true --strict=true --no-interactive 

The results of the code being generated domonstrate the extra characters

1 ng-clerk-shared--domain // note the duplicated --
2 ng-clerk-shared--domain.component.{css,html,specs,component} / note the duplicated --
3 All referenes to the generated "@xom/ng-clerk/shared//domain, including tsconfig.base.json contains this duplicated /

Maybe a little tweaking of the generators should correct this anamoly.
Cheers

What would it take to add support for react?
Where are the main places to change the current generators etc?

I've been browsing through the code and see the following potential changes/modifications:

export enum Language {
  Angular = 'ng',
}

Which could obviously be changed to Framework and React added as a value

export enum Framework {
  Angular = 'ng',
  React = 'react'
}

create-app

export const isAppFolderExisting = (framework: string, tree: Tree): boolean => {
  return tree
    .children('libs')
    .some((appGroupingFolder) =>
      appGroupingFolder.startsWith(framework)
    );
};

FE app generator

  const { framework, name, baseFolder } = options;
  if (!isAppFolderExisting(framework, tree)) {
    await initialiseAngularWorkspace(tree);
  }

To initialise FE framework workspace

export const initialiseFrameworkWorkspace = (tree: Tree): GeneratorCallback => {
  addEslintLayerConstraints(tree);
  return addDependencies(tree);
};

create-domain

leave unchanged

move

leave unchanged

remove

leave unchanged

ng-add

leave unchanged

react-add

export async function reactAddGenerator(tree: Tree) {
  return addDependenciesToPackageJson(
    tree,
    {},
    {
      '@nrwl/react': 'latest',
      '@nrwl/cypress': 'latest',
    }
  );
}
export default reactAddGenerator;

export const reactAddSchematic = convertNxGenerator(reactAddGenerator);

shared

leave unchanged

src/generators

component

Change to ng-component

react-component

Copy ng-component folder

• Modify files to have a single tsx file and perhaps a .spec.tsx file
• Remove lib and model folders
• Modify generator.ts accordingly

create (create new generator)

leave unchanged

libraries

Modify generator.js slightly to adjust for react framework option

const normalizeOptions = (
  options: LibrariesGeneratorSchema
): LibrariesNormalizedSchema => {
  return {
    ...options,
    libraryDefinitions: getDomainLibraryDefinitions(
      options.application,
      options.domain,
      options.libraries,
      options.framework // support diff FE frameworks
    ),
  };
};

import { wrapAngularDevkitSchematic } from '@nrwl/devkit/ngcli-adapter';
import { wrapReactDevkitSchematic } from '@nrwl/devkit/react-adapter';

const devKitSchematicFrameworkMap = {
  angular: wrapAngularDevkitSchematic,
  react: wrapReactDevkitSchematic
}

  const wrapDevkitSchematic = devKitSchematicFrameworkMap[options.framework]
  const libraryGenerator = wrapDevkitSchematic(
    `@nrwl/${options.framework}`,
    'library'
  );

... leave the rest mostly unchanged it seems

Storybook interaction testing is a new feature in beta.

See the below for more information:

• https://storybook.js.org/blog/interactive-stories-beta/
• https://itnext.io/cypress-component-testing-vs-storybook-interaction-testing-fe1f0270d30a
• https://testing-library.com/

Using storybook interaction testing instead of the current cypress component test runner approach would make the generators more simple as it would:

• Remove the cypress folder and files created to enable the cypress component test runner target
• Remove the CDK test harness setup
• I think it would also make sense to remove the cypress component testing code. At the moment, it uses an Angular interceptor. Using mock service worker would allow the mocked calls to show in the network tab.

It would be more cross platform than the current approach which is Angular specific.

I created a nx module-federation app following the instructions ad dynamic-module-federation-with-angular#creating-a-new-dynamic-host-applicationr. To create the application do the following at the command prompt:

  # Crate an empty workspace
  npx create-nx-workspace@latest --preset=empty --pm=pnpm
  pnpm add -D @nx/angular @nx/workspace

# create the module-federation dynamic host - replace
nx g @nx/angular:host medsoft --dynamic --standalone --standaloneConfig --no-interactive

# create the module-federation remote 
nx g @nx/angular:remote registration --host medsoft --standalone --standaloneConfig --no-interactive   

Run the application

nx serve medsoft

Now that the application works at http://localhost:4200/, install @srleecode/domain with

pnpm add -D @srleecode/domain

Open the project withs Visual studio code and click on installed nx extension icon.
Click generate and select appGrouping foldder:

Note the error in the terminal

installed packages are shown below:

{
   "name": "@xom/source",
   "version": "0.0.0",
   "license": "MIT",
   "scripts": {},
   "private": true,
   "dependencies": {
      "@angular/animations": "~16.0.0",
      "@angular/common": "~16.0.0",
      "@angular/compiler": "~16.0.0",
      "@angular/core": "~16.0.0",
      "@angular/forms": "~16.0.0",
      "@angular/platform-browser": "~16.0.0",
      "@angular/platform-browser-dynamic": "~16.0.0",
      "@angular/router": "~16.0.0",
      "rxjs": "~7.8.0",
      "tslib": "^2.3.0",
      "zone.js": "~0.13.0"
   },
   "devDependencies": {
      "@angular-architects/ddd": "^3.1.1",
      "@angular-devkit/build-angular": "~16.0.0",
      "@angular-devkit/core": "~16.0.0",
      "@angular-devkit/schematics": "~16.0.0",
      "@angular-eslint/eslint-plugin": "~16.0.0",
      "@angular-eslint/eslint-plugin-template": "~16.0.0",
      "@angular-eslint/template-parser": "~16.0.0",
      "@angular/cli": "~16.0.0",
      "@angular/compiler-cli": "~16.0.0",
      "@angular/language-service": "~16.0.0",
      "@nx/cypress": "16.2.1",
      "@nx/eslint-plugin": "16.2.1",
      "@nx/jest": "16.2.1",
      "@nx/js": "16.2.1",
      "@nx/linter": "16.2.1",
      "@nx/web": "16.2.1",
      "@nx/workspace": "16.2.1",
      "@schematics/angular": "~16.0.0",
      "@srleecode/domain": "^13.10.18",
      "@types/jest": "^29.4.0",
      "@types/node": "16.11.7",
      "@typescript-eslint/eslint-plugin": "^5.58.0",
      "@typescript-eslint/parser": "^5.58.0",
      "cypress": "^12.11.0",
      "eslint": "~8.15.0",
      "eslint-config-prettier": "8.1.0",
      "eslint-plugin-cypress": "^2.10.3",
      "jest": "^29.4.1",
      "jest-environment-jsdom": "^29.4.1",
      "jest-preset-angular": "~13.1.0",
      "nx": "16.2.1",
      "nx-cloud": "latest",
      "prettier": "^2.6.2",
      "ts-jest": "^29.1.0",
      "ts-node": "10.9.1",
      "typescript": "~5.0.2"
   }
}

Thanks for helping