Add more Markdown plugins

[ilyatitovich]

Fixes #140

I started working on custom plugins for remark. The first plugin I decided to make is a plugin for checking the correct capitalization of words in titles.

Additional packages have been installed: unified-lint-rule and unist-util-visit. This packages allow us to create custom rules for remark.

What does the plugin do?

Plugin formats the title, compares it with the current one and issues a warning with the expected variant and what was found.

I decided to do full formatting of the title so that the plugin shouldn't skip some strange mistakes, for example ExAmplE woRd. If user needs to leave the spelling of a word, he can add it to the exclusion list.

The formated title is saved in cache, which allow us to avoid repeated calculations if the same title is found in other documents.

Logic

To detect articles and other words that, according to the rules, should be written with a small letter, I created an object where these words will be stored. This will allow us to quickly find the desired exception by checking the key.

I added the ability to send to the plugin a list of exception words that the linter should skip. This will allow us to bypass the rules if the author believes that the word should retain its spelling.

The linter also skip words written in uppercase. It is understood that such writing is the original intention of the author.

Linter will detect if the first word in the title is capitalized (even if it is usually written in lowercase) and will suggest capitalizing it.

The result of the plugin's work currently looks like this:

This is the first project of this kind for me, I’m looking forward to the review! :)

Motivation

Our own plugins will allow us to find specific errors in .md files.

Checklist

• [x] Don’t rush. Check all changes in PR again.
• [x] Run pnpm test.
• [x] Think about changing documentation.
  • If you added a script to scripts/, add a comment with a description.
  • If you added a new folder, add its description to the project’s README.md.
  • If you added config, describe how we use this tool in the config’s comment.
  • If you added something to the project’s architecture, describe it in the project’s README.md.
  • Try to focus on “why?”, not “how?”.
• [x] If you added a new dependency, check our requirements.
• [ ] Think about testing
  • If you added a feature, add unit tests.
  • If you added a new state to the UI, add visual tests.
  • If you fixed the bug, think about preventing bug regression in the future.
• If you changed web client:
  • [ ] Think about moving code to core/. What code will also be useful on other platforms?
  • [ ] Run pnpm size and check the difference in the JS bundle size. Is it relevant to the changes? Change the limit in web/.size-limit.json if necessary.
  • [ ] Think about keyboard UX. Is it easy to use the new feature with only one hand on a keyboard? Is it easy to understand what keys to press?
  • [ ] Think about HTML semantics.
  • [ ] Think about accessibility. Check a11y recommendations. Think about how screen reader users will use the tool. Is it easy to use on a screen with bad contrast?
  • [ ] Think about translations. Will
  • [ ] Think about right-to-left languages. What parts of the screen should be mirrored for Arabic or Hebrew languages?
• If you changed the colors token in the web client:
  • [ ] Think about app loading styles inlined in index.html.
• If you changed core/:
  • [ ] Think about making types more precise. Can you better explain data relations by type?
  • [ ] Think about conflict resolution. We don’t need some very smart changing merging; just 2 changes of the same item on different clients should not break the database. What if the user changes an item on one machine and removes it on another?
  • [ ] Think about log and storage migration.
• If you changed English translations:
  • [ ] Change translation ID if you change the meaning of the text.

[ai]

I am closing this since we have separated PRs