@dsivd/prestations-ng 17.10.9 → 18.0.0-beta.10

package/CONTRIBUTING.md

@@ -2,11 +2,11 @@
 
 ## Prerequisite
 
--   Node 20.11+
--   npm 10.2+
--   Chrome or Chromium
--   G++
--   The variable `CHROMIUM_BIN` set in your environment
+- Node 20.11+
+- npm 10.2+
+- Chrome or Chromium
+- G++
+- The variable `CHROMIUM_BIN` set in your environment
 
 If you're using bashrc.dev.pee, the variable `CHROMIUM_BIN` is already set to `~/slave-apps/chromium-headless-64/chrome`
 
@@ -33,17 +33,17 @@ result.
 
 ### In **prestations-ng**
 
--   if it is the first time, execute `npm install` then `npm run build:lib` (at root level)
--   `cd dist/prestations-ng && yarn link` (it's critical to link the content of `dist/prestations-ng`, not the root)
--   `cd ../.. && npm run build:lib:dev` (at root level)
+- if it is the first time, execute `npm install` then `npm run build:lib` (at root level)
+- `cd dist/prestations-ng && yarn link` (it's critical to link the content of `dist/prestations-ng`, not the root)
+- `cd ../.. && npm run build:lib:dev` (at root level)
 
 `build:lib:dev` will use a feature of the Angular CLI: `--watch`. For more information on `--watch`, refer to the [official documentation](https://github.com/angular/angular-cli/blob/master/docs/documentation/stories/create-library.md#why-do-i-need-to-build-the-library-everytime-i-make-changes).
 
 ### In the prestation
 
--   `cd front`
--   `yarn link @dsivd/prestations-ng`
--   `npm start` (only when `npm run build:lib:dev` in `prestations-ng` has started)
+- `cd front`
+- `yarn link @dsivd/prestations-ng`
+- `npm start` (only when `npm run build:lib:dev` in `prestations-ng` has started)
 
 Now if you change something in `prestations-ng`, the CLI of the prestation will hot swap the missing pieces and reload the page.
 
@@ -62,8 +62,8 @@ of `prestations-ng`.
 
 ### Tips
 
--   Add logic into `utility` folder so you can reuse them in `ng-add` and `ng-update`.
--   Create a proper schematic such as [update-karma-config](projects/prestations-ng/schematics/update-karma-config/index.ts) to be able to test it into a project when the library is linked.
+- Add logic into `utility` folder so you can reuse them in `ng-add` and `ng-update`.
+- Create a proper schematic such as [update-karma-config](projects/prestations-ng/schematics/update-karma-config/index.ts) to be able to test it into a project when the library is linked.
 
 ### Testing
 
@@ -71,16 +71,16 @@ run `npm run test:schematics` (at root level).
 
 ### Testing into a project such as **skeleton**
 
--   **In prestations-ng**:
+- **In prestations-ng**:
 
-    -   if it is the first time, execute `npm install` then `npm run build:lib` (at root level)
-    -   `cd dist/prestations-ng && npm link` (it's critical to link the content of `dist/prestations-ng`, not the root)
-    -   `npm run build:lib:dev` (at root level)
+    - if it is the first time, execute `npm install` then `npm run build:lib` (at root level)
+    - `cd dist/prestations-ng && npm link` (it's critical to link the content of `dist/prestations-ng`, not the root)
+    - `npm run build:lib:dev` (at root level)
 
--   **In project**:
-    -   `cd front`
-    -   `npm link @dsivd/prestations-ng` (`npm unlink @dsivd/prestations-ng` to remove link)
-    -   `ng g @dsivd/prestations-ng:[YOUR_SCHEMATIC]` (i.e. `ng g @dsivd/prestations-ng:ng-add` or `ng g @dsivd/prestations-ng:update-karma-config` or `ng g @dsivd/prestations-ng:replace-browsers-list`)
+- **In project**:
+    - `cd front`
+    - `npm link @dsivd/prestations-ng` (`npm unlink @dsivd/prestations-ng` to remove link)
+    - `ng g @dsivd/prestations-ng:[YOUR_SCHEMATIC]` (i.e. `ng g @dsivd/prestations-ng:ng-add` or `ng g @dsivd/prestations-ng:update-karma-config` or `ng g @dsivd/prestations-ng:replace-browsers-list`)
 
 In your project, you can test any schematic added into [collection.json](projects/prestations-ng/schematics/collection.json).
 If you want to test `ng-update`, you will need to release the library under a beta version and then update your version of prestations-ng.
@@ -93,9 +93,9 @@ In case you're adding or modifying a `*.module.ts`, please update [MODULES.md](M
 
 ## Adding an icon
 
--   Create a `.ts` and `.html` similar to `foehn-icon-lock.component`, and replace the name of the icon accordingly
--   Add a `title` for accessibility
--   Import and export the new `*.component.ts` in [foehn-icons.module.ts](projects/prestations-ng/src/foehn-icons/foehn-icons.module.ts)
+- Create a `.ts` and `.html` similar to `foehn-icon-lock.component`, and replace the name of the icon accordingly
+- Add a `title` for accessibility
+- Import and export the new `*.component.ts` in [foehn-icons.module.ts](projects/prestations-ng/src/foehn-icons/foehn-icons.module.ts)
 
 ## Notes about linting, formatting and pre-commit hooks
 
@@ -103,9 +103,9 @@ This project uses a set of scripts to lint and format the code, along with pre-c
 
 Important scripts are :
 
--   `npm run lint` : run ESLint and Prettier on all files
--   `npm run format`: run ESLint and Prettier on all files and fix errors automatically
--   `npm run validate`: clean and run all tests
+- `npm run lint` : run ESLint and Prettier on all files
+- `npm run format`: run ESLint and Prettier on all files and fix errors automatically
+- `npm run validate`: clean and run all tests
 
 **Husky** is used as a pre-commit hook to automatically output linting and formatting errors for staged files before committing.
 In the end, this utilitary calls `npm run lint-staged` which you can also call yourself of course. To have this pre-commit hook,
@@ -114,13 +114,13 @@ use the correct node version in the settings, otherwise it might fail. Same thin
 
 ## Before committing
 
--   **Make sure you have installed pre commit hook by running :** `npm run huskyInstall`
--   Remove unnecessary `console.log`
--   Update [CHANGELOG.md](CHANGELOG.md)
--   Have it up to date with `npm install`
--   If you want to autofix lint/format errors in your code : `npm run format`
--   Run all tests `npm run validate`
--   Ensure the commit message contains a Jira reference
+- **Make sure you have installed pre commit hook by running :** `npm run huskyInstall`
+- Remove unnecessary `console.log`
+- Update [CHANGELOG.md](CHANGELOG.md)
+- Have it up to date with `npm install`
+- If you want to autofix lint/format errors in your code : `npm run format`
+- Run all tests `npm run validate`
+- Ensure the commit message contains a Jira reference
 
 > On commit, Husky will run ESLint and Prettier on all changed files. If you still want to run both on all files, please read the sections above.
 
@@ -141,23 +141,23 @@ Please use the dedicated Jenkins build:
 
 **Then**
 
--   Choose [Lancer un build avec des paramètres](https://validation.portail.etat-de-vaud.ch/outils/jenkinsdgnsi/view/METIMT/job/AAC_Release_Prestakit//build?delay=0sec) in the left menu
--   Uncheck **RELEASE_BE** and check **RELEASE_NG** (if not already checked)
--   Choose **origin/master** as **SOURCE_BRANCHE**
--   Add version number in **TARGET_VERSION** (i.e.: 1.2.3) but before check in tags list if your version doesn't already exist
--   Nothing in **NEXT_VERSION**
--   Choose **STABLE** in **NPM_TAG** when certain that your release is stable otherwise choose **NEXT** which will publish a **v1.2.3-BETA** on NPM
--   Check **RUN_TEST** if you wish to validate the library's test (can take a while)
+- Choose [Lancer un build avec des paramètres](https://validation.portail.etat-de-vaud.ch/outils/jenkinsdgnsi/view/METIMT/job/AAC_Release_Prestakit//build?delay=0sec) in the left menu
+- Uncheck **RELEASE_BE** and check **RELEASE_NG** (if not already checked)
+- Choose **origin/master** as **SOURCE_BRANCHE**
+- Add version number in **TARGET_VERSION** (i.e.: 1.2.3) but before check in tags list if your version doesn't already exist
+- Nothing in **NEXT_VERSION**
+- Choose **STABLE** in **NPM_TAG** when certain that your release is stable otherwise choose **NEXT** which will publish a **v1.2.3-BETA** on NPM
+- Check **RUN_TEST** if you wish to validate the library's test (can take a while)
 
 Alternatively, you can manually publish the package. Although this method is not recommended.
 
--   Ensure you can push to the npm registry: `npm adduser --registry=https://registry.npmjs.org --scope=@dsivd`
--   Update the version number in `package.json` either manually or with `npm version`
--   Commit and tag the version change
--   Package a new version of the library with `npm package`
--   Publish the package:
-    -   `npm run publish:stable` for stable version (released to everybody)
-    -   `npm run publish:next` for next version (development only)
+- Ensure you can push to the npm registry: `npm adduser --registry=https://registry.npmjs.org --scope=@dsivd`
+- Update the version number in `package.json` either manually or with `npm version`
+- Commit and tag the version change
+- Package a new version of the library with `npm package`
+- Publish the package:
+    - `npm run publish:stable` for stable version (released to everybody)
+    - `npm run publish:next` for next version (development only)
 
 ## Maintaining branches (LTS)
 
@@ -169,27 +169,27 @@ Let's assume we want to add a fix in the version `v10.16.10`.
 
 **If `release/v10` doesn't exist**
 
--   Checkout the latest `v10` tag of the version to fix: `git checkout tags/v10.xx.xx -b release/v10` (replace xx.xx by the latest version)
--   Push the branch directly to the remote : `git push origin release/v10:release/v10`
+- Checkout the latest `v10` tag of the version to fix: `git checkout tags/v10.xx.xx -b release/v10` (replace xx.xx by the latest version)
+- Push the branch directly to the remote : `git push origin release/v10:release/v10`
 
 **Then**
 
--   Checkout the target release branch: `git checkout origin/release/v10 -b release/v10`
--   Create a new local branch for your fix: `git checkout -b My_Fix_Branch`
--   Develop and test your fix, then commit it
--   Push your local branch to a remote branch: `git push origin My_Fix_Branch:bugfix/My_Fix_Branch`
--   Create a pull request from `bugfix/My_Fix_Branch` to `release/v10`
--   Merge the pull request
--   Then go on [Jenkins](https://validation.portail.etat-de-vaud.ch/outils/jenkins-pee/job/AAC_Release_Prestakit/) for appropriated build
--   Choose [Lancer un build avec des paramètres](https://validation.portail.etat-de-vaud.ch/outils/jenkins-pee/job/AAC_Release_Prestakit/build?delay=0sec) in the left menu
--   Uncheck **RELEASE_BE** and check **RELEASE_NG** (if not already checked)
--   Choose **origin/release/v10** as **SOURCE_BRANCHE**
--   Add version number in **TARGET_VERSION** (i.e.: 10.16.11) but before check in tags list if your version doesn't already exist
--   Nothing in **NEXT_VERSION**
--   Choose **LTS** in **NPM_TAG**
--   Check **RUN_TEST** if you wish to validate the library's test (can take a while)
--   Merge `release/v10` to `master` so we won't loose this fix
--   Release `master` as per README.md instructions
+- Checkout the target release branch: `git checkout origin/release/v10 -b release/v10`
+- Create a new local branch for your fix: `git checkout -b My_Fix_Branch`
+- Develop and test your fix, then commit it
+- Push your local branch to a remote branch: `git push origin My_Fix_Branch:bugfix/My_Fix_Branch`
+- Create a pull request from `bugfix/My_Fix_Branch` to `release/v10`
+- Merge the pull request
+- Then go on [Jenkins](https://validation.portail.etat-de-vaud.ch/outils/jenkins-pee/job/AAC_Release_Prestakit/) for appropriated build
+- Choose [Lancer un build avec des paramètres](https://validation.portail.etat-de-vaud.ch/outils/jenkins-pee/job/AAC_Release_Prestakit/build?delay=0sec) in the left menu
+- Uncheck **RELEASE_BE** and check **RELEASE_NG** (if not already checked)
+- Choose **origin/release/v10** as **SOURCE_BRANCHE**
+- Add version number in **TARGET_VERSION** (i.e.: 10.16.11) but before check in tags list if your version doesn't already exist
+- Nothing in **NEXT_VERSION**
+- Choose **LTS** in **NPM_TAG**
+- Check **RUN_TEST** if you wish to validate the library's test (can take a while)
+- Merge `release/v10` to `master` so we won't loose this fix
+- Release `master` as per README.md instructions
 
 ## Improving Compilation Performance
 

package/ESLINT_MIGRATION_GUIDE.md

@@ -26,8 +26,8 @@ git add .
 
 In your `angular.json` file:
 
--   Update the lint `builder` for other projects such as `skeleton-e2e` for example and invoke `@angular-eslint/builder:lint` instead of tslint builder.
--   Then replace `tsConfig` and `exclude` options with `lintFilePatterns` option and add path to your .html and .ts files
+- Update the lint `builder` for other projects such as `skeleton-e2e` for example and invoke `@angular-eslint/builder:lint` instead of tslint builder.
+- Then replace `tsConfig` and `exclude` options with `lintFilePatterns` option and add path to your .html and .ts files
 
 Before:
 
@@ -92,7 +92,6 @@ You can replace the content of your `.eslintrc.json` with the following `json`.
         '/karma.conf.js',
         '/.eslintrc.json',
         '/tsconfig*.json',
-        '/src/tsconfig*.json',
         '/src/main.ts',
         '/src/typings.d.ts'
     ],
@@ -114,13 +113,7 @@ You can replace the content of your `.eslintrc.json` with the following `json`.
                 project: ['tsconfig.json'],
                 createDefaultProgram: true
             },
-            plugins: [
-                'import',
-                'jsdoc',
-                'rxjs',
-                'rxjs-angular',
-                'simple-import-sort'
-            ],
+            plugins: ['import', 'rxjs', 'rxjs-angular', 'simple-import-sort'],
             extends: [
                 'plugin:@angular-eslint/recommended',
                 'plugin:@angular-eslint/template/process-inline-templates',
@@ -129,8 +122,7 @@ You can replace the content of your `.eslintrc.json` with the following `json`.
                 'plugin:import/recommended',
                 'plugin:import/errors',
                 'plugin:import/warnings',
-                'plugin:import/typescript',
-                'plugin:jsdoc/recommended'
+                'plugin:import/typescript'
             ],
             rules: {
                 /* @angular-eslint */
@@ -355,13 +347,7 @@ You can replace the content of your `.eslintrc.json` with the following `json`.
                 'simple-import-sort/exports': 'error',
                 'import/first': 'error',
                 'import/newline-after-import': 'error',
-                'import/no-duplicates': 'error',
-                /* @jsdoc */
-                'jsdoc/check-alignment': 'error',
-                'jsdoc/check-indentation': 'error',
-                'jsdoc/no-types': 'error',
-                'jsdoc/require-param-type': 'off',
-                'jsdoc/require-returns-type': 'off'
+                'import/no-duplicates': 'error'
             }
         },
         // HTML
@@ -384,7 +370,7 @@ You can replace the content of your `.eslintrc.json` with the following `json`.
         {
             files: ['src/**/*.spec.ts', 'src/**/*.d.ts'],
             parserOptions: {
-                project: 'src/tsconfig.spec.json'
+                project: 'tsconfig.spec.json'
             },
             extends: ['plugin:jasmine/recommended'],
             plugins: ['jasmine'],
@@ -429,33 +415,33 @@ When you are done with your migration and happy with the result, you can delete
 
 **tslint.json**
 
--   Remove file because replaced by `.eslintrc.json`
+- Remove file because replaced by `.eslintrc.json`
 
 **package.json**
 
--   removed `tslint`, `codelyzer` and `@angular-eslint/schematics` dependencies
+- removed `tslint`, `codelyzer` and `@angular-eslint/schematics` dependencies
 
 **.editorconfig**
 
--   replace `tslint.json` with `.eslintrc.json`
--   replace `.angular-cli.json` with `angular.json` (**if needed**)
--   remove `indent_style = space` (**if redundant**)
+- replace `tslint.json` with `.eslintrc.json`
+- replace `.angular-cli.json` with `angular.json` (**if needed**)
+- remove `indent_style = space` (**if redundant**)
 
 ## Configurating IntelliJ IDEA to use ESLint as your JavaScript linter
 
--   To configure ESLint automatically in the current project, open "_File -> Settings..._" (`Ctrl+Alt+S`) and either:
+- To configure ESLint automatically in the current project, open "_File -> Settings..._" (`Ctrl+Alt+S`) and either:
 
-    -   Search for `ESLint`
+    - Search for `ESLint`
 
     or
 
-    -   Navigate to "_Languages & Frameworks -> Code Quality Tools -> ESLint_"
+    - Navigate to "_Languages & Frameworks -> Code Quality Tools -> ESLint_"
 
     and check radio box "_Automatic ESLint configuration_"
 
--   To configure ESLint automatically in all new projects, open "_File -> Other Settings -> Setting for New Projects..._" and follow step just above when configuration in a current project.
+- To configure ESLint automatically in all new projects, open "_File -> Other Settings -> Setting for New Projects..._" and follow step just above when configuration in a current project.
 
--   Fix problems automatically on save (**requires Intellij 2020.1 or higher**): See:
-    -   [IntelliJ IDEA 2020.1](https://www.jetbrains.com/help/idea/2020.1/eslint.html#ws_js_eslint_activate) and read section "_Detecting and fixing problems on save_"
-    -   [IntelliJ IDEA 2020.2](https://www.jetbrains.com/help/idea/2020.2/eslint.html#ws_js_eslint_activate) and read section "_Activating and configuring ESLint in IntelliJ IDEA_" bullet point 6
-    -   [IntelliJ IDEA 2020.3](https://www.jetbrains.com/help/idea/2020.3/eslint.html#ws_js_eslint_activate) and read section "_Fix problems automatically on save_"
+- Fix problems automatically on save (**requires Intellij 2020.1 or higher**): See:
+    - [IntelliJ IDEA 2020.1](https://www.jetbrains.com/help/idea/2020.1/eslint.html#ws_js_eslint_activate) and read section "_Detecting and fixing problems on save_"
+    - [IntelliJ IDEA 2020.2](https://www.jetbrains.com/help/idea/2020.2/eslint.html#ws_js_eslint_activate) and read section "_Activating and configuring ESLint in IntelliJ IDEA_" bullet point 6
+    - [IntelliJ IDEA 2020.3](https://www.jetbrains.com/help/idea/2020.3/eslint.html#ws_js_eslint_activate) and read section "_Fix problems automatically on save_"