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>
3.2 KiB
Pull Request Process
Pull Requests (PRs) are a fantastic way to contribute back to the project. It's one of the fastest ways to see a bug fix or new feature you care about land in the platform.
Reviewing and maintaining community submitted code is a very time consuming process. To ensure the core team can give every PR the tender love and care it deserves, and not let valuable PRs go stale, we require that:
Every pull request must be in answer to an existing open Issue.
We use GitHub Issues as a living to-do list of tasks to work on next. Each PR resolving a related issue ensures that it aligns with the core team's planning and long-term goals. Please leave a comment on the issue related to your PR so you can be marked as the assignee. This ensures no one else will accidentally work on the same issue at the same time.
Choosing What to Implement
We welcome PRs for any Issue. Issues labeled "Community" have been identified as good improvements or fixes for community members, as they're often a little more scoped in what they affect. This in turn makes it easier to implement the change and review the work. Issues labeled "Good First Issue" are typically easier to resolve for those who haven't contributed to the codebase before, and are therefore a great starting point.
Implementing an Accepted Feature Request
If you're looking to implement a feature request that hasn't been converted to an issue yet, please contact the core team through a comment on the feature request before starting work. There's probably a good reason it isn't ready-to-be-implemented yet (unknown timelines, conflicts with other projects, blockers, etc). By collaborating early, we ensure your PR can be merged as efficiently as possible!
Copyright License Agreement (CLA)
All code contributors are required to sign the Contributor License Agreement (CLA). When you start a pull request, a GitHub Action will prompt you to review the CLA and sign it by adding your name to contributors.yml. To clarify the intellectual property rights in the project and any Contributions, Directus requires that You accept the Contributor License Agreement. This license is for Your protection as a contributor as well as the protection of Directus, recipients of software distributed or made available by Directus, and other contributors; it does not change your rights to use your own Contributions for any other purpose.
Changesets
To properly generate changelogs and determine the right version number after a change is merged, we rely on changesets. Each pull request should include a changeset that describes whether the change is a patch/minor/major version bump, and describe what the change is. Changesets should be written in past tense.