92621429ee
* add docs to eslint
* update prettier ignore
* fix vitepress linting
* eslint ignore fixes
* prettier run
* update prettier ignore
* fix formatting
* enable linting of markdown files
* revert format command change
* fix irregular whitespace
* update dictionary
* (Changelog) Create four-boxes-shake.md
* Rework ESLint / Prettier setup
- Disable js/ts/vue files for Prettier to ensure linting/formatting is
only happening via ESLint
- Rework formatting of code blocks in md files
- Disable formatting of code blocks in md files under '/docs' by Prettier
- Instead use "eslint-plugin-markdown" to format & __lint__ js*/ts*/vue such code blocks
- Replace unmaintained "eslint-plugin-md" plugin by official "eslint-plugin-markdown" plugin
- I'll check whether we can use this to format other code blocks
(json, html, ...) as well
- Restructure, clean-up and apply some fixes to the ESLint config
(Note: Not ready for flat config yet since not supported by
vscode-eslint)
- Enable cache for ESLint / Prettier in scripts
- Clean-up ignore file
- Explicit folder declaration (.../)
- Don't ignore all 'extensions' folders in ESLint (only
'/api/extensions/')
- Enable formatting in '/.github' folder
* Fix all formatting issues with Prettier
* Update md files under /docs/.typedocs
* Fix lint issues in vue/js files
* ESLint / Prettier config revision v2
Enable Prettier for md code blocks, but only as warnings since it can
get into the way with Vitepress md extensions like '[!code ...]'
comments
* Remove prettier-ignore comments
* Make spellchecker happy
* Remove changeset
* Revert lint setup for code blocks
There are many cases in the docs where linting / formatting of code
blocks doesn't make
sense:
- Code block is only an excerpt - linter fails
- Code block contains special comments (e.g. markdown extensions) which
needs to remain at the same place - formatting would break it
- ...
* Apply lint issues / formatting from temp lint setup
* Run formatter
* Fix merge failure
* Simplify & modernize ESLint / Prettier setup
No longer run Prettier via ESLint. Nowadays, this is the recommended
setup. There's no real need to run it this way, it's just an additional
layer.
Add VS Code settings to make the work with the new setup easier.
* Remove unused eslint disable directives
* Make editorconfig more useful
* Fix formatting issues reported by editorconfig
* Format files with Prettier
* Enable formatting of source translations file
* Format source translations file
* Remove unnecessary console error
* Remove unnecessary line
* Only ignore md files under .changeset
* Add CI reporter for Prettier
* Fail job on wrongly formatted files
* Fix format
* Test Prettier action on changed/added file
* Use simple CI format check for now & no cache
* Revert "Test Prettier action on changed/added file"
This reverts commit 4f7d8826ad.
* Introduce code blocks check for docs
* Fix code block issues
* Ignore auto-generated packages dir
* Fix comment position
* Also lint `/app/.storybook`
* Reformat modified files
---------
Co-authored-by: Pascal Jufer <pascal-jufer@bluewin.ch>
Co-authored-by: Rijk van Zanten <rijkvanzanten@me.com>
4.2 KiB
description, readTime
| description | readTime |
|---|---|
| An introduction to the process, rules and guidelines that for all code contributions to Directus. | 6 min read |
Contributing
Heya! Welcome to Directus, and thank you for taking the time to contribute back to our project! ❤️
There are many ways in which you can contribute, but before you do, please make sure you're aware of the Code of Conduct. Our contributors and maintainers work extremely hard to maintain Directus as premium open-source software. Please be respectful of those efforts throughout our ecosystem. Trolling, harassing, insulting, or other unacceptable behavior by participants will not be tolerated.
Code Contributions
Check out our docs providing an overview to the codebase, how to run Directus locally for development, and how to write and run tests.
Create a Pull Request
The whole Directus project is open source, and community code contributions are always welcome! Fixing issues or implementing new features is an excellent way to contribute back to the platform.
Please do make sure you read through our Pull Request Process before you start! That ensures you have the highest likelihood that your contribution will make it to the core codebase.
Community Contributions
We love all kinds of community contributions, including making our online spaces as respectful and productive as possible, running in-person user groups throughout the world, or producing educational material to support developers in understanding and implementing Directus.
Sponsorship & Advocacy
Directus requires significant resources to build and maintain, especially as our community rapidly grows. You can support the project by becoming a GitHub Sponsor, by providing testimonials and reviews, and by sharing Directus with others.
Other Ways To Support Directus
Request a New Feature
If you have a great idea for an improvement of the platform, or any other feedback, please make sure to open a new discussion on our GitHub Discussions board. Feature requests are reviewed and triaged according to our feature request workflow. For more information, please see our process for handling feature requests.
Report a Bug
If you happen to run into a bug, please post an issue on our main GitHub Issue board.
Please be as detailed as you can in the bug report. The more information available, the easier it is for other contributors to help you find a solution. For example, it might be worth adding a schema snapshot file or a database dump.
Report Security Vulnerability
If you believe you have discovered a security vulnerability within a Directus product or service, please reach out to us directly over email: security@directus.io. We will then open a GitHub Security Advisory for tracking the fix.
We value the members of the independent security research community who uncover issues and work with our core team to release patches. Our policy is to credit all researchers in the fix's release notes. In order to receive credit, security researchers must follow responsible disclosure practices, including:
- They do not publish the vulnerability prior to the Directus team releasing a fix for it
- They do not divulge exact details of the issue, for example exploits or proof-of-concepts
Translate the App
Every button, element, and other piece of text in the app is fully translatable, providing full internationalization for the Directus platform. Our Crowdin integration makes creating and updating translations a breeze. Lear more about how we implement community translations into Directus.