Guildelines

To prevent any functional regression in GenesisX after making changes, it is crucial to perform quick and thorough testing and validation. Therefore, it is mandatory for contributors to follow the checklist below after making any changes, be it to a package, functional code, linting or testing, dependencies, build pipeline, or documentation. This will ensure that the application has not been impacted negatively by the changes and functions as intended.

1. Run the tests: After making any change, run the tests to ensure that all the existing functionality is working as expected. If any tests fail, investigate the failure and fix the issue before proceeding.
2. Check for lint errors: Run the linter to ensure that the code conforms to the project's coding standards. If there are any lint errors, fix them before proceeding.
3. Review the documentation: If the change involves modifying the documentation, make sure to review the changes to ensure that they are accurate and complete(npm run docs).
4. Check the build pipeline: If the change involves modifying the build pipeline, make sure to test the pipeline to ensure that it is working as expected.
5. Validate the functionality: After making any change, validate the functionality to ensure that it is still working as expected. Test all the use cases that the change affects and ensure that there are no regressions.
6. Review the dependencies: If the change involves modifying the dependencies, review the changes to ensure that they are correct and don't introduce any security vulnerabilities or performance issues. By following this checklist, contributors can ensure that any changes made to GenesisX are thoroughly tested and validated, and that the application has not regressed in any way.

Code check-in and Commit

1. Branch names in this project must adhere to this contract: ^(feature|upgrade|chore|fix|test|lib|docs|perf|release|hotfix)\/[a-z0-9._-]+$.
2. Commit message must adhere to this prefix: fix:/docs:/feat:/chores: etc dependents on the change

Testing changes

To validate changes made in GenesisX, two levels of validation are necessary.

1. Firstly, the GenesisX package builds and other commands should work without any issues.
2. Secondly, the package usage, including generate and serve, should function correctly in both new and existing workspaces.

NOTE : Please note that while editing this file, it's recommended that you disable word wrap in your text editor so that you can edit the table below without any formatting issues. Also, to generate the content for the table below from an Excel spreadsheet, you can use the following website.

Excel to Markdown

Count	Step	Command	Validation Result
1	Inside Genesisx Repo : After making Changes
1.a	Node Version Check	nvm use 18	Node version should be 18
1.b	Cleanup node packages	rm -rf node\_modules yarn.lock yarn-error.log package-lock.json	should be successful
1.c	Reinstall node packages	yarn install	should be successful
1.d	Lint	nx lint <package>	Lint command should work fine if present
1.e	Test	nx test <package>	Test cases should pass
1.f	Build the package	nx build package	Package should be built in /dist/packages/<package>
1.g	The package version should be updated in package.json before build. For ongoing development and testing of packages use the beta version approach when publishing. For example if the current version of the package is 2.3.5 change this to 2.3.5-beta.0, then publish the package from the dist folder to npm and test your changes. If you make more changes then keep incrementing the last version number before publishing the package again, for example 2.3.5-beta.1 and so on. Once you are satisfied with your changes to the package, change the version back to the original format like so 2.3.6 with the last version number incremented, then publish to npm.	npm publish dist/packages/<package> --access public	package should be published check on npm registry
2	New Workspace : Testing changed packages
2.a	Create a new workspace / or use your existing genesis app workpace but don’t do it inside the main genesis repo Choose a simple generator like JenkinsFile	npx @genesisx/create-workspace	New Workspace should be created successfully
2.b	Switch to the new workspace	cd <newWorkspace> or open It via vscode and cleanup node_modeules
2.c	Node Version Check	nvm use 18	Node version should be 18
2.d	Install Node packages	yarn install	should be successful
2.e	Install the new package changed above, using the recent published version	yarn add @genesisx/<package>@<version> (versions) OR yarn add @genesisx/<package>	package should be installed under  node\_modules/@genesisx/<package>
2.f	Generate a new app using that package make sure to use the command from  Genesisx/Packages/<package>/Readme.md	example for react nx generate @genesisx/react:templated demo-react-1	App Should be crated under <newWorkspace>/apps/<appName>
2.g	Serve the app and access it on localhost	nx serve <appName> like for above one nx serve demo-react-1	Should see the homepage of the app on localhost:4201  or whatever is mentioned in the logs
2.h	Additonally do the build, test, lint for the generated new app	nx build <appName> etc	Should work fine
3	Test all Packages: Perform the Section 2 for unchanged packages also if it’s a common change like version dependency change etc else only the impacted package can be tested	Same as above in section 2	Same result as in section 2
3.a	Make sure the combination of apps working fine like Graphql federation of services via mock-server	nx build <appName> etc	Should work fine
3.b	React apps working with inter-app routing and similar testing for next, jenkins and other packages	nx build <appName> etc	Should work fine

---

Testing your package changes in new workspace without publishing

Copy the built package code from genesis/dist/packages/package to new-Genesisx-Workspace/node_modules/@genesisx/package:

1. Install the package via npm registry: If you haven't installed the package before, install it via npm registry in the new workspace using the command npm install @genesisx/package.
2. Copy the built package code: Copy the built package code from genesis/dist/packages/package to new-Genesisx-Workspace/node_modules/@genesisx/package. Make sure to copy only the changed files from dist like generator.js or project.json.
3. Test the changes: After copying the changed files, test the package in the new workspace to ensure that the changes are working as expected. By following these steps, you can avoid publishing every change to NPM and test the recent changes in packages quickly and efficiently.

Jenkins Pipeline Job

Please make sure the below pipeline works fine for your branch (PR)

https://jenkins.in.pscloudhub.com/job/Genesis-Packages-Publish-Jobs/job/package-build-job/

This pipeline runs build, lint, unit test, test coverage and a static analysis using SonarQube for all packages.

You can view the static analysis report here: sonar-report

Still facing some issue

Follow the troubleshooting page for some tips