lmc-eu · literat · Sep 6, 2024 · Aug 22, 2024 · Aug 28, 2024 · Aug 28, 2024
@@ -0,0 +1,23 @@
+# Changelog is autogenerated
+CHANGELOG.md
+example-changelog.md
+vendor
+dist
+build
+.github
+
+# Temporary disabled packages
+# we will fix them incrementally
+analytics
+codemods
+common
+configs
+design-tokens
+demo
+docs
+examples
+exporters
+form-validations
+icons
+web-twig
+web-react
@@ -0,0 +1,23 @@
+import config from '@almacareer/remark-config';
+
+export default {
+  ...config,
+  plugins: [
+    ...config.plugins,
+    // Values should increment by one from the first item
+    // @see: https://github.com/remarkjs/remark-lint/tree/main/packages/remark-lint-ordered-list-marker-value
+    ['remark-lint-ordered-list-marker-value', 'ordered'],
+
+    // Do not check blank lines between list items
+    // @see: https://github.com/remarkjs/remark-lint/tree/main/packages/remark-lint-list-item-spacing
+    ['remark-lint-list-item-spacing', false],
+
+    // @see: https://github.com/ilyatitovich/remark-lint-heading-capitalization
+    [
+      'remark-lint-heading-capitalization',
+      {
+        lowerCaseWords: ['eu/spirit', '@lmc', 'spirit/node', 'spirit/jsdom', 'v1', 'v2', 'v3'],
+      },
+    ],
+  ],
+};
@@ -1,27 +1,27 @@
-# Contributing to `@lmc-eu/spirit-design-system`
+# Contributing to Spirit Design System
 
 First of all, thanks for your contribution to this project! ❤️
 Here are some tips how to make your contributing efforts efficient and eventually accepted & merged:
 
 - [General Usage](#general-usage)
 - [Decisions](#decisions)
-- [Project structure](#project-structure)
+- [Project Structure](#project-structure)
 - [Development](#development)
 - [Commit Conventions](#commit-conventions)
-- [Code style](#code-style)
+- [Code Style](#code-style)
 - [Documenting the Components](#documenting-the-components)
 - [Testing](#testing)
 - [Publishing](#publishing)
 
-## General usage
+## General Usage
 
 This project uses `makefile` for managing various chores, like dependency installation, testing, linting etc. Make sure you run `make` right after you clone the repository - it will set you up with everything needed to get started. Once you are done with that, have a look at what commands (targets) are available for you to run using `make` - `make install` etc.
 
 ## [Decisions](https://github.com/lmc-eu/spirit-design-system/blob/main/docs/decisions/README.md)
 
 The reasoning behind various decisions made for the Spirit Design System. A good historical record.
 
-## Project structure
+## Project Structure
 
 This project is a monorepo managed by [Lerna][lerna-home]. This means that each folder inside the [packages/][packages] directory represents a package published to npm. The root directory also contains _package.json_ file but this is only used for local development purposes and does not represent something that is ever published to npm (you might notice that it only contains _devDependencies_ and no prod dependencies 🤷‍♂️).
 
@@ -40,7 +40,7 @@ This format leads to **easier-to-read commit history**.
 
 Each commit message consists of a **header**, a **body**, and a **footer**.
 
-```
+```txt
 <header>
 <BLANK LINE>
 <body>
@@ -57,7 +57,7 @@ The `footer` is optional. The [Commit Message Footer](#commit-footer) format des
 
 #### Commit Message Header
 
-```
+```txt
 <type>(<scope>): <short summary>
   │       │             │
   │       │             └─⫸ Summary in present tense. Sentence case. No period at the end.
@@ -132,7 +132,7 @@ The footer can contain information about breaking changes and deprecations and i
 
 For example:
 
-```
+```txt
 BREAKING CHANGE: <breaking change summary>
 <BLANK LINE>
 <breaking change description + migration instructions>
@@ -142,7 +142,7 @@ Fixes #<issue number>
 
 The breaking change section SHOULD start with the phrase "BREAKING CHANGE: " followed by a summary of the breaking change, a blank line, and a detailed description of the breaking change that also includes migration instructions.
 
-### Revert commits
+### Revert Commits
 
 If the commit reverts a previous commit, it SHOULD begin with `Revert: `, followed by the header of the reverted commit.
 
@@ -151,7 +151,7 @@ The content of the commit message body SHOULD contain:
 - information about the SHA of the commit being reverted in the following format: `This reverts commit <SHA>`,
 - a clear description of the reason for reverting the commit message.
 
-### Before commit:
+### Before Commit
 
 Test your code before committing with `% yarn test` or `% yarn packages:test`. It will run type linting, code listing, testing, and code formatting.
 
@@ -169,7 +169,7 @@ This project uses Prettier for code formatting. You can run `make format` to for
    1. The table MUST be placed in a section introduced by a headline called `API`.
    2. The table MUST contain the following columns:
       - `Name` — the name of the prop, e.g. `title`
-      - `Type` — the type of the prop, e.g. `string`, `number`, `bool`, `[horizontal | vertical]`, an existing [dictionary], etc.
+      - `Type` — the type of the prop, e.g. `string`, `number`, `bool`, `[horizontal | vertical]`, an existing [dictionary][dictionary], etc.
       - `Default` — the default value of the prop, e.g. `null` or `—` (em-dash) if there is no default value
       - `Required` — if the prop is required `✓` or not `✕`
       - `Description` — the description of the prop, e.g. `Title of the accordion`
@@ -187,23 +187,23 @@ The testing script includes:
 - checking types using the [Typescript][typescript] compiler
 - running unit test using the [Jest][jest]
 
-### Unit testing
+### Unit Testing
 
 You can run unit testing via `test:unit` scripts.
 For all available scripts see the package's `package.json` file.
 
-### Manual testing
+### Manual Testing
 
 For a better testing experience, we are using deploy previews on Netlify.
 If your modification affects the publishable code and when you create a PR, every push then will be deployed to Netlify.
 Netlify will create a deploy preview and you can test your changes there.
 Netlify will also attach a link to the deploy preview to your PR so you can easily access it.
 
-#### Readable Netlify links
+#### Readable Netlify Links
 
 For a better UI experience when searching for the deploy preview link, you can use this [Gist with userContent.css][netlify-preview-gist].
 
-### Visual regression testing
+### Visual Regression Testing
 
 **Prerequisites:** [Docker][docker] 🐳
 
@@ -231,7 +231,7 @@ We have two test suites and you can find them in the `./tests/e2e` directory:
 
 👉 To save time and repository size, we test only in the Chromium browser and only on the desktop viewport.
 
-#### On CI pipeline
+#### On CI Pipeline
 
 In CI we use Netlify to test against.
 
@@ -257,7 +257,7 @@ For more, please read the article [How to Run GitHub Actions Locally with the ac
 
 This project uses GitHub Actions to publish the packages automatically to npm. New packages are published after the new tag is pushed to the main branch. PR can be merged only by the appropriate group of maintainers.
 
-### Steps to create a new package version
+### Steps to Create a New Package Version
 
 1. Merge all appropriate PRs you want to publish into the main branch
 2. Run the `make version` command to bump the version number in packages (a new version number is determined automatically based on commit history)
@@ -271,15 +271,13 @@ This project uses GitHub Actions to publish the packages automatically to npm. N
 [act-article]: https://www.freecodecamp.org/news/how-to-run-github-actions-locally/
 [conventional-commits]: https://www.conventionalcommits.org
 [commitlint-config]: https://github.com/lmc-eu/code-quality-tools/tree/main/packages/commitlint-config
-[conventional-commits]: https://www.conventionalcommits.org
 [dictionary]: https://github.com/lmc-eu/spirit-design-system/tree/main/docs/DICTIONARIES.md
 [developer-handbook]: https://github.com/lmc-eu/spirit-design-system/tree/main/docs/contributtion/development.md
 [docker]: https://www.docker.com/
 [eslint]: https://eslint.org/
 [jest]: https://jestjs.io/
 [lerna-home]: https://lernajs.io
 [netlify-preview-gist]: https://gist.github.com/adamkudrna/694f3048c1338f07375b9b8af24afe2f
-[nx-cloud]: https://nx.app/
 [packages]: packages/
 [playwright]: https://playwright.dev/
 [prettier]: https://prettier.io/

@@ -1,18 +1,25 @@
+<!--lint disable no-file-name-mixed-case -- mixed case in the file name for version -->
+
 # Deprecations
 
 Introducing deprecations and feature flags to be removed in the version 2 lists.
 
 💁 Please follow these steps to safely upgrade your Design System to Spirit Design System v2 components.
 
-## spirit-web v2
+<!-- @see: https://github.com/ilyatitovich/remark-lint-heading-capitalization/issues/13 -->
+<!--lint disable heading-capitalization -->
+
+## @lmc-eu/spirit-web v2
 
 - [Deprecations][web-deprecations-v2]
 
-## spirit-web-react v2
+## @lmc-eu/spirit-web-react v2
 
 - [Deprecations][web-react-deprecations-v2]
 
-## spirit-web-twig v2
+## @lmc-eu/spirit-web-twig v2
+
+<!--lint enable heading-capitalization -->
 
 - _spirit-web-twig_ was released as version 2 already. See the [CHANGELOG][twig-changelog] for more details or refer to the [migration guide][twig-migration-v2].
 

@@ -1,10 +1,17 @@
+<!--lint disable no-file-name-mixed-case -- mixed case in the file name for version -->
+
 # Deprecations
 
 Introducing deprecations and feature flags to be removed in the version 3 lists.
 
 💁 Please follow these steps to safely upgrade your Design System to Spirit Design System v3 components.
 
-## spirit-web-twig v3
+<!-- @see: https://github.com/ilyatitovich/remark-lint-heading-capitalization/issues/13 -->
+<!--lint disable heading-capitalization -->
+
+## @lmc-eu/spirit-web-twig v3
+
+<!--lint enable heading-capitalization -->
 
 - [Deprecations][web-twig-deprecations]
 

@@ -38,8 +38,9 @@
     "test:e2e:report": "yarn playwright show-report",
     "test:e2e:ui": "yarn playwright test --ui",
     "types": "yarn packages:types",
-    "lint": "npm-run-all --parallel es:lint packages:lint",
+    "lint": "npm-run-all --parallel es:lint lint:markdown packages:lint",
     "lint:fix": "npm-run-all --parallel es:lint:fix packages:lint:fix",
+    "lint:markdown": "remark ./ --quiet",
     "packages:lint:fix": "lerna run lint:fix --parallel",
     "packages:lint": "lerna run lint --parallel --no-sort",
     "packages:start": "lerna run start --parallel",
@@ -55,7 +56,8 @@
     "version": "yarn format:fix:changelog"
   },
   "devDependencies": {
-    "@babel/core": "7.24.7",
+    "@almacareer/remark-config": "^0.1.0",
+    "@babel/core": "7.25.2",
     "@babel/preset-react": "7.24.7",
     "@commitlint/cli": "17.8.1",
     "@lmc-eu/commitlint-config": "2.0.2",
@@ -90,6 +92,8 @@
     "react-dom": "18.3.1",
     "react-syntax-highlighter": "15.5.0",
     "react-textarea-autosize": "8.5.3",
+    "remark-cli": "^12.0.1",
+    "remark-lint-heading-capitalization": "^1.2.0",
     "sass-loader": "14.2.1",
     "style-loader": "4.0.0",
     "typescript": "4.7.4",

@@ -14,7 +14,7 @@
 
 This is an example of a typical file structure of a component:
 
-```
+```txt
 ├── src
     ├── scss
     │   └── components
@@ -60,7 +60,7 @@ Similarly, component's tools serve as a storage of component-scoped:
 
 ## Linking Design Tokens
 
-Components can (and should!) reuse Spirit [design tokens].
+Components can (and should!) reuse Spirit [design tokens][design-tokens].
 
 Component's theme properties can be linked to design tokens. This way, the
 appearance of individual components is always unified and coherent: **anytime
@@ -71,7 +71,7 @@ discussion between Spirit developers and designers. Linking component
 properties to design tokens needs to be done carefully **in order for the design
 to work as a system.**
 
-Default Spirit design tokens live in the [`spirit-design-tokens`] package.
+Default Spirit design tokens live in the [`spirit-design-tokens`][design-tokens] package.
 Products may define their own design tokens as long as they preserve the same
 structure and naming.
 
@@ -85,7 +85,7 @@ the [`@tokens` API][tokens-api] with
 From the implementation point of view, design tokens are Sass variables
 organized in Sass modules. Within component styles, Sass modules with design
 tokens are referred to just by filename. However, because the modules do not
-exist in the place they are called in (the [`spirit-design-tokens`] package is
+exist in the place they are called in (the [`spirit-design-tokens`][design-tokens] package is
 stored in `node_modules`), the correct load path for the desired set of design
 tokens must be [provided on build time][configuring-load-path]. This is the only
 way how Sass modules can be affected from outside, without giving in their
@@ -193,7 +193,7 @@ great portion of encapsulation, traceability, and more.
 <summary>Does <code>@use</code> behave the same way as <code>@import</code>?</summary>
 
 In most situations, no. Most importantly, while `@import` loads everything into
-global context, `@use` is scoped and works more like `import` in [ES modules].
+global context, `@use` is scoped and works more like `import` in [ES modules][es-modules].
 
 </details>
 
@@ -217,12 +217,11 @@ To avoid conflicts, we need a convention to distinguish situations when somethin
 - `id` attribute can be used by **JS only**.
 </details>
 
-[design tokens]: https://github.com/lmc-eu/spirit-design-system/tree/main/packages/design-tokens
-[`spirit-design-tokens`]: https://github.com/lmc-eu/spirit-design-system/tree/main/packages/design-tokens
+[design-tokens]: https://github.com/lmc-eu/spirit-design-system/tree/main/packages/design-tokens
 [tokens-api]: https://github.com/lmc-eu/spirit-design-system/tree/main/packages/design-tokens#tokens-api
 [configuring-load-path]: https://github.com/lmc-eu/spirit-design-system/tree/main/packages/design-tokens#configuring-load-path
 [rebranding]: https://github.com/lmc-eu/spirit-design-system/tree/main/packages/web#rebranding
 [design-tokens-faq]: https://github.com/lmc-eu/spirit-design-system/tree/main/packages/design-tokens#faq
 [sass-modules]: https://sass-lang.com/blog/the-module-system-is-launched
-[es modules]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Modules
+[es-modules]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Modules
 [sass-true]: https://github.com/oddbird/true
@@ -1,5 +1,10 @@
+<!-- @see: https://github.com/ilyatitovich/remark-lint-heading-capitalization/issues/13 -->
+<!--lint disable heading-capitalization -->
+
 # @lmc-eu/spirit-web
 
+<!--lint enable heading-capitalization -->
+
 > CSS implementation of Spirit Design System.
 
 ## Install
@@ -73,7 +78,7 @@ module.exports = {
 
 Some components require JavaScript plugins for their full functionality. You can use individual modules or compiled bundle.
 
-#### Individual or compiled
+#### Individual or Compiled
 
 Plugins can be included individually as an EcmaScript module (using `import { <plugin> } from '@lmc-eu/spirit-web'`, see [Using Spirit Web as a module](#using-spirit-web-as-a-module)), or all at once using `js/{cjs|esm|bundle}/spirit-web.js` or the minified `js/{cjs|esm|bundle}/spirit-web.min.js` (do not include both), all files are UMD ready.
 
@@ -83,7 +88,7 @@ Plugins can be included individually as an EcmaScript module (using `import { <p
 
 If you use a bundler (Webpack, Rollup, ...), you can use `/js/*.js` files which are EcmaScript modules.
 
-#### Using Spirit Web as a module in browser
+#### Using Spirit Web as a Module in Browser
 
 We provide a version of Spirit Web as `ESM` (`spirit-web.esm.js` and `spirit-web.esm.min.js`) which allows you to use Spirit Web as a module in your browser.
 
@@ -95,7 +100,7 @@ We provide a version of Spirit Web as `ESM` (`spirit-web.esm.js` and `spirit-web
 </script>
 ```
 
-#### Data attributes
+#### Data Attributes
 
 Nearly all Spirit-Web plugins can be enabled and configured through HTML alone with data attributes (our preferred way of using JavaScript functionality).
 Be sure to only use one set of data attributes on a single element (e.g., you cannot trigger a tooltip and modal from the same button.).
@@ -136,7 +141,7 @@ var modal = new Modal(myModalEl); // initialized with defaults
 
 If you’d like to get a particular plugin instance, each plugin exposes a `getInstance` method.
 
-#### CSS selectors in constructors
+#### CSS Selectors in Constructors
 
 You can also use a CSS selector as the first argument instead of a DOM element to initialize the plugin.
 Currently the element for the plugin is found by the `querySelector` method since our plugins support a single element only.
@@ -171,7 +176,7 @@ Learn more in the [`spirit-design-tokens` docs][rebranding].
 
 Start local development server with `yarn start` to get started. You will get the live preview of all components and plugins in your browser. Just get dirty and change something and you will see the changes live.
 
-The dev-stack is based on [Vite].
+The dev-stack is based on [Vite][vite].
 
 ## Deprecations
 
@@ -186,7 +191,7 @@ Check your browser console to see if you are using any of the deprecated functio
 
 ## Examples
 
-👀 See [examples] for a live demo.
+👀 See [examples][examples] for a live demo.
 
 ## License