diff --git a/.github/workflows/code-check.yml b/.github/workflows/code-check.yml index e896296f7b..1447d3a4d2 100644 --- a/.github/workflows/code-check.yml +++ b/.github/workflows/code-check.yml @@ -22,6 +22,16 @@ env: NX_SKIP_NX_CACHE: ${{ inputs.skipNxCache }} jobs: + markdown-link-check: + runs-on: ubuntu-latest + steps: + - uses: actions/checkout@master + - uses: gaurav-nelson/github-action-markdown-link-check@v1 + with: + base-branch: 'main' + config-file: '.github/workflows/markdown.links.config.json' + folder-path: 'packages/,apps/,tools/' + test: strategy: fail-fast: false diff --git a/.github/workflows/markdown.links.config.json b/.github/workflows/markdown.links.config.json new file mode 100644 index 0000000000..a343b0b81e --- /dev/null +++ b/.github/workflows/markdown.links.config.json @@ -0,0 +1,8 @@ +{ + "replacementPatterns": [ + { + "pattern": "/%40", + "replacement": "/@" + } + ] +} diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 87e0c3aed7..d0dc96371e 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -61,7 +61,7 @@ To ease the process, we are providing a set of: * [Editors configuration](.editorconfig) * [Linters configuration](./packages/@o3r/eslint-config-otter/README.md) -* [Component generator](./docs/core/OTTER_ANGULAR_TOOLS.md#schematics) (and more) +* [Component generator](./packages/@o3r/core/README.md#generators) (and more) ## Code review process diff --git a/apps/vscode-extension/package.json b/apps/vscode-extension/package.json index 36a740d351..ac59540361 100644 --- a/apps/vscode-extension/package.json +++ b/apps/vscode-extension/package.json @@ -41,7 +41,10 @@ }, "otter.styling.variable.types": { "type": "array", - "default": ["color", "string"], + "default": [ + "color", + "string" + ], "items": { "type": "string" } diff --git a/docs/README.md b/docs/README.md index 4cd3b3c3db..88d16805f1 100644 --- a/docs/README.md +++ b/docs/README.md @@ -18,7 +18,7 @@ The documentation is sorted by topic but in the table below, you shall find the | @o3r/extractors | Utilities to extract your application metadata to interact with your CMS | @o3r/core
@o3r/dev-tools | | | @o3r/forms | Utilities to enhance angular form (asynchronous decorator, additional validator, error store...) | @o3r/core
@o3r/dev-tools | [README](./forms/README.md)
[FORM_ERRORS](./forms/FORM_ERRORS.md)
[FORM_STRUCTURE](./forms/FORM_STRUCTURE.md)
[FORM_SUBMIT_AND_INTERCOMMUNICATION](./forms/FORM_SUBMIT_AND_INTERCOMMUNICATION.md)
[FORM_VALIDATION](./forms/FORM_VALIDATION.md) | | @o3r/localization | Provide a fallback language/translation support and debug tools | @o3r/core
@o3r/dev-tools | [LOCALIZATION](./localization/LOCALIZATION.md)
[CMS_ADAPTERS](./cms-adapters/CMS_ADAPTERS.md) | -| @o3r/logger | Bridge to target different logger (logrocket, fullstory, smartlook) with a common interface | N/A | [LOGS](./logger/LOGS.md) | +| @o3r/logger | Bridge to target different logger (logrocket, fullstory, smartlook) with a common interface | N/A | [LOGS](./logger/LOGS.md) | | @o3r/mobile | Helpers and store to integrate Capacitor into your Otter application.
Integration with the pCloudy API for e2e testing on real devices. | @o3r/core
@o3r/logger | | | @o3r/routing | Module to configure an Otter application's routing (POST parameter management, preloading strategy, guard recommendation) | @o3r/core
@o3r/dev-tools | [REQUEST_PARAMETERS_SERVICE](./routing/REQUEST_PARAMETERS_SERVICE.md)
[ROUTING](./routing/ROUTING.md)
[APP_SERVER_ROUTING](./routing/APP_SERVER_ROUTING.md) | | @o3r/rules-engine | Rule engine executed on your Otter application to customize your application translations, placeholders and configs based on a json file generated by your CMS | @o3r/components
@o3r/configuration
@o3r/core
@o3r/dev-tools
@o3r/dynamic-content
@o3r/extractors
@o3r/localization
@o3r/logger
@o3r/styling | [how-it-works](./rules-engine/how-it-works.md)
[how-to-use](./rules-engine/how-to-use.md)
[examples](./rules-engine/examples.md)
[facts](./rules-engine/facts.md)
[operators](./rules-engine/operators.md)
[rule](./rules-engine/rule.md)
[ruleset](./rules-engine/ruleset.md)
[CMS_ADAPTERS](./cms-adapters/CMS_ADAPTERS.md) | @@ -28,5 +28,5 @@ The documentation is sorted by topic but in the table below, you shall find the | @o3r/styling | Styling framework to apply a theme on an Otter application at build time and runtime to support CMS customization | @o3r/core
@o3r/dynamic-content
@o3r/extractors
@o3r/schematics | [THEME](./styling/THEME.md)
[TYPOGRAPHY](./styling/TYPOGRAPHY.md)
[CMS_ADAPTERS](./cms-adapters/CMS_ADAPTERS.md) | | @o3r/testing | Testing (e2e, unit test) utilities to help you build your own E2E pipeline integrating visual testing | @o3r/localization
@o3r/schematics | [POST_MESSAGE_INTERCEPTOR](./testing/POST_MESSAGE_INTERCEPTOR.md)
[UNIT_TESTS_SETUP](./testing/UNIT_TESTS_SETUP.md) | | @o3r/third-party | Bridge to communicate with third parties via an iFrame solution | N/A | [A/B Testing](./ab-testing/AB_TESTING.md) | -| @o3r/vscode-extension | Various in house VSCode extensions to help you with the development of your Otter application with this IDE (automated generated Otter components etc.) | N/A | [vscode-extension](./vscode-extension.md) | -| @o3r/eslint-config-otter | Recommended eslint configuration for Otter project | @o3r/eslint-plugin | [eslint-config](./linter/eslint-config.md) | +| @o3r/vscode-extension | Various in house VSCode extensions to help you with the development of your Otter application with this IDE (automated generated Otter components etc.) | N/A | [vscode-extension](../apps/vscode-extension/README.md) | +| @o3r/eslint-config-otter | Recommended eslint configuration for Otter project | @o3r/eslint-plugin | [eslint-config](./linter/eslint-config.md) | diff --git a/docs/core/DEVELOPER.md b/docs/core/DEVELOPER.md index 639934ec35..6d0e74928e 100644 --- a/docs/core/DEVELOPER.md +++ b/docs/core/DEVELOPER.md @@ -3,7 +3,7 @@ ## Where to define the ng-update migrations? -To be recognized by the __ng-cli as update schematics__, we have to define our migrations schematics in +To be recognized by the __ng-cli as update schematics__, we have to define our migrations schematics in __package.json__, _ng-update_ section of the package which contains the updates, in our case __@o3r/core__ ```json "ng-update": { @@ -11,7 +11,7 @@ __package.json__, _ng-update_ section of the package which contains the updates, } ``` -The content of migration.json is as follows: +The content of migration.json is as follows: ex: ```json { @@ -25,23 +25,23 @@ ex: "migration-v3_2": { "version": "3.2.0-alpha.0", // version to update to "description": "Updates of the Otter Library v3.2.x", - "factory": "./schematics/ng-update/index#updateV3_2" // relative path to the schematics factory function to execute + "factory": "./schematics/ng-update/index#updateV3_2" // relative path to the schematics factory function to execute } } } -``` +``` -When we run the update on _@o3r/core_ (```yarn ng update @o3r/core```) in our app, ng-cli will install the latest version of @o3r/core and -it will check the ng-update section in the package.json of the new installed version, to see if there are updates to execute. -Based on the starting version of @o3r/core and the new installed one, the cli will run the schematics which are between these 2 versions from migration.json -Here are 2 scenarios: +When we run the update on _@o3r/core_ (```yarn ng update @o3r/core```) in our app, ng-cli will install the latest version of @o3r/core and +it will check the ng-update section in the package.json of the new installed version, to see if there are updates to execute. +Based on the starting version of @o3r/core and the new installed one, the cli will run the schematics which are between these 2 versions from migration.json +Here are 2 scenarios: ### Scenario 1 -- Application in otter 3.0, latest stable version of otter is 3.2 +- Application in otter 3.0, latest stable version of otter is 3.2 Based on the above _migration.json_ the cli will run __migration-v3__ and __migration-v3_2__ because the versions '3.1.0-alpha.0' and '3.2.0-alpha.0' defined in migration.json are between 3.0 (old version) and 3.2 (latest stable) ### Scenario 2 -- Application in otter 3.1, latest stable version of otter is 3.2 +- Application in otter 3.1, latest stable version of otter is 3.2 Based on the above _migration.json_ the cli will run __migration-v3_2__ because the version '3.2.0-alpha.0' defined in migration.json is the only one between 3.0 (old version) and 3.2 (latest stable) @@ -49,8 +49,8 @@ Based on the above _migration.json_ the cli will run __migration-v3_2__ because To be easier to test in local, when we need to create/update schematics, we can use the schematics cli. 1. install @angular-devkit\schematics-cli on the app, if needed (no need to commit the change) - 2. link (yarn link or cpx) @o3r/core in the app - 3. run: + 2. link (yarn link or cpx) @o3r/core in the app + 3. run: ```node ./node_modules/@angular-devkit/schematics-cli/bin/schematics.js ./node_modules/@o3r/core/collection.json:update-otter --dry-run=false --force``` One mention for step 3 is that you have to add a new entry in _@o3r/core/collection.json_ to point to the update schematic @@ -62,15 +62,6 @@ One mention for step 3 is that you have to add a new entry in _@o3r/core/collect ``` No need to commit this change. -## Testing your schematic with the PR version number - -When you have done the development on the schematic, next steps are required to test that your schematic is working with the normal way of running it (not the way used in dev chapter) -Steps: - - all steps are executed at app level; - 1. modify _.npmrc_ of the app to target the _otter-pr_ versions - @o3r:registry=https://pkgs.dev.azure.com/AmadeusDigitalAirline/Otter/_packaging/otter-pr/npm/registry/ (don't forget auth tokens) - - 2. run: yarn ng update @o3r/core@prVersion --force - ex: ``` yarn ng update @o3r/core@5.4.0-alpha.21-pr.115535 --force``` +## Testing your schematic with the PR version number -The command above will run all schematics update for all packages defined in "ng-update" -> "packageGroup" section in `package.json` file of _@o3r/core_ +Please refer to the [Verdaccio](../../.verdaccio/README.md) setup. diff --git a/docs/core/START_NEW_APPLICATION.md b/docs/core/START_NEW_APPLICATION.md index 8d609260be..9946d4e700 100644 --- a/docs/core/START_NEW_APPLICATION.md +++ b/docs/core/START_NEW_APPLICATION.md @@ -45,7 +45,7 @@ export class AppModule { } ``` You will also find recommendations for your application such accessibility configuration like the -[Application Reduced Motion](docs/application/REDUCED_MOTION.md) +[Application Reduced Motion](../application/REDUCED_MOTION.md) It will also update your ``angular.json`` with the feature enabled for your project. This will configure the different generators to create components and services consistent with your project. diff --git a/docs/localization/LOCALIZATION.md b/docs/localization/LOCALIZATION.md index 9dce121812..c14166609b 100644 --- a/docs/localization/LOCALIZATION.md +++ b/docs/localization/LOCALIZATION.md @@ -19,7 +19,7 @@ Localization module is built on top of an open source [ngx-translate](https://gi - Fallback language. In case some resource key does not exist in language X, the loader tries to fetch translation bundle from the endpoint location in fallback language Y in the first place and ends by loading json bundles from the application (root of dist folder **/** by default) if previous steps have failed (bundles output path in dist folder is also configurable via a shell option). -- Resource keys can be translated from templates (*.html) via a [pipe](https://github.com/ngx-translate/core/blob/master/projects/ngx-translate/core/src/lib/translate.pipe.ts) or [directive](https://github.com/ngx-translate/core/blob/master/projects/ngx-translate/core/src/lib/translate.directive.ts) as well as from typescript (*.ts) via a [service](https://github.com/ngx-translate/core/blob/master/projects/ngx-translate/core/src/lib/translate.service.ts). +- Resource keys can be translated from templates (*.html) via a [pipe](https://github.com/ngx-translate/core/blob/master/packages/core/lib/translate.pipe.ts) or [directive](https://github.com/ngx-translate/core/blob/master/packages/core/lib/translate.directive.ts) as well as from typescript (*.ts) via a [service](https://github.com/ngx-translate/core/blob/master/packages/core/lib/translate.service.ts). - Support for resource keys with parameters @@ -29,7 +29,7 @@ Localization module is built on top of an open source [ngx-translate](https://gi - Intelligent fallback support. For any un-supported language request, localization service fallback to fallback locale map language OR first nearest supported language. More information in the `intelligent fallback` section below. -- Ability to toggle translations on and off to help identify the key corresponding to a translation. +- Ability to toggle translations on and off to help identify the key corresponding to a translation. # How to use @@ -407,7 +407,7 @@ import { LazyMessageFormatConfig, LocalizationModule, translateLoaderProvider, - TranslateMessageFormatLazyCompiler + TranslateMessageFormatLazyCompiler } from "@o3r/localization"; import { TranslateModule } from "@ngx-translate/core"; import { MESSAGE_FORMAT_CONFIG } from 'ngx-translate-messageformat-compiler'; @@ -446,8 +446,8 @@ class AppModule {} ### How to localize plural expression -For pluralizations, we are using _TranslateMessageFormatCompiler_, coming from [ngx-translate-messageformat-compiler](https://www.npmjs.com/package/ngx-translate-messageformat-compiler) package, which is a compiler for _ngx-translate_ that uses _messageformat.js_ to compile translations using ICU syntax for handling pluralization and gender. -[ICU Message Format](http://userguide.icu-project.org/formatparse/messages) is a standardized syntax for dealing with the translation of user-visible strings into various languages that may have different requirements for the correct declension of words (e.g. according to number, gender, case) - or to simplify: pluralization. +For pluralizations, we are using _TranslateMessageFormatCompiler_, coming from [ngx-translate-messageformat-compiler](https://www.npmjs.com/package/ngx-translate-messageformat-compiler) package, which is a compiler for _ngx-translate_ that uses _messageformat.js_ to compile translations using ICU syntax for handling pluralization and gender. +[ICU Message Format](http://userguide.icu-project.org/formatparse/messages) is a standardized syntax for dealing with the translation of user-visible strings into various languages that may have different requirements for the correct declension of words (e.g. according to number, gender, case) - or to simplify: pluralization. Simple pluralization rules like _0, 1 or other_ fits well for English but may not fit for many other languages (Eastern Europe languages, Asiatic languages) where pluralization rules are much more complex. If this does not fit your requirement we recommend to reformulate your text, so that you do not need to use pluralization. Example: instead of saying 'You have added 2 baggages' you may want to say 'Pieces of baggage: 2' which should be fine for most languages no matter which number is considered to be plural. #### Integration with ngx-translate @@ -492,7 +492,7 @@ import {MESSAGE_FORMAT_CONFIG} from 'ngx-translate-messageformat-compiler'; ``` The value of _translations.nbOfErrors_ is the translation key 'o3r-list-inline-messages-pres.nbOfErrors'. The next step translates the key passing some parameters to translate pipe. __Output__ -The output will be +The output will be - _No errors_ if _countMessages_ is 0 - _1 error_ if _countMessages_ is 1 - _'Value of count messages' errors_ if _countMessages_ is greater than 1 (ex: 10 Errors) @@ -508,7 +508,7 @@ Sometimes you may want to display a different resource based on some property va ``` ```typescript -// in component html +// in component html