From 04230cd6548d1b8a206625c153a769c912fdccdd Mon Sep 17 00:00:00 2001 From: Daniel Roe Date: Fri, 15 Jul 2022 11:03:57 +0100 Subject: [PATCH 1/8] docs: add back module creation section --- docs/content/5.community/3.contribution.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/docs/content/5.community/3.contribution.md b/docs/content/5.community/3.contribution.md index 6fdfd7cc132..bcda36d07ef 100644 --- a/docs/content/5.community/3.contribution.md +++ b/docs/content/5.community/3.contribution.md @@ -36,13 +36,14 @@ If you are adding a new feature or refactoring or changing the behavior of Nuxt When submitting your PR, there is a simple template that you have to fill out. Please tick all appropriate "answers" in the checklists. - +If you've built something with Nuxt that's cool, why not [extract it into a module](/guide/going-further/modules), so it can be shared with others? We have [many excellent modules already](https://modules.nuxtjs.org/), but there's always room for more. + +If you need help while building it, feel free to [check in with us](/community/getting-help). -Mainly, make sure your PR title adheres to [Conventional Commits guidelines](https://www.conventionalcommits.org/en/v1.0.0/), and do link the related issue (feature request or bug report) in the issue description. ## Documentation Guide From 2255d19eced05df54c9c0ffae77cf17df2f28273 Mon Sep 17 00:00:00 2001 From: Daniel Roe Date: Fri, 15 Jul 2022 14:08:15 +0100 Subject: [PATCH 2/8] docs: expand contribution guide for ecosystem Co-authored-by: Anthony Fu --- docs/content/5.community/3.contribution.md | 193 ++++++++++++------ .../5.community/4.framework-contribution.md | 87 ++++++++ .../{4.roadmap.md => 5.roadmap.md} | 0 3 files changed, 213 insertions(+), 67 deletions(-) create mode 100644 docs/content/5.community/4.framework-contribution.md rename docs/content/5.community/{4.roadmap.md => 5.roadmap.md} (100%) diff --git a/docs/content/5.community/3.contribution.md b/docs/content/5.community/3.contribution.md index bcda36d07ef..ca37f045b8c 100644 --- a/docs/content/5.community/3.contribution.md +++ b/docs/content/5.community/3.contribution.md @@ -4,83 +4,171 @@ Nuxt is a community project - and so we love contributions of all kinds! ❤️ There is a range of different ways you might be able to contribute to the Nuxt ecosystem. -## Triage issues and help out in discussions +## Ecosystem -Check out [our issues board](https://github.com/nuxt/framework/issues) and [discussions](https://github.com/nuxt/framework/discussions). Helping other users, sharing workarounds, creating reproductions, or even poking into a bug a little bit and sharing your findings makes a huge difference. +The Nuxt ecosystem includes many different projects and organizations. For example: -## Fixing a bug or adding a feature +* [nuxt/](https://github.com/nuxt) - core repositories for the Nuxt framework itself. Currently [**nuxt/framework**](https://github.com/nuxt/framework) contains Nuxt 3 and [**nuxt/nuxt.js**](https://github.com/nuxt/nuxt.js) contains Nuxt 2. +* [nuxt-community/](https://github.com/nuxt-community) - community-contributed and maintained modules and libraries. There is a [process to migrate a module](/gduide/going-further/modules/#joining-nuxt-community) to `nuxt-community`. While these modules have individual maintainers, they are not dependent on a single person. +* [nuxt-contrib/](https://github.com/nuxt-contrib) - the previous home for libraries that are not specific to Nuxt but produced and used by the Nuxt team. +* [unjs/](https://github.com/unjs) - many of these libraries are used throughout the Nuxt ecosystem. They are designed to be universal libraries that are framework- and environment-agnostic. We welcome contributions and usage by other frameworks and projects. -Before you fix a bug or add a feature, ensure **there's an issue that describes it**. Particularly for new features, this is an excellent opportunity for the project leads to giving feedback before starting work on it. +## How to contribute -### Examples +### Triage issues and help out in discussions -While working on your PR, you will likely want to check if your changes are working correctly. +Check out the issues and discussions for the project you want to help. For example, here are [the issues board](https://github.com/nuxt/framework/issues) and [discussions](https://github.com/nuxt/framework/discussions) for Nuxt 3. Helping other users, sharing workarounds, creating reproductions, or even poking into a bug a little bit and sharing your findings makes a huge difference. -You can modify the example app in `playground/`, and run it with `yarn dev`. Please make sure not to commit it to your branch, but it could be helpful to add some example code to your PR description. This can help reviewers and other Nuxt users understand the feature you've built in-depth. + -Every new feature should have a corresponding unit test (if possible). The `test` folder in this repository is currently a work in progress, but do your best to create a new test following the example of what's already there. +### Send a pull request -Before creating a PR or marking it as ready-to-review, ensure that all tests pass by running `yarn test` locally. +We always welcome pull requests! ❤️ -### Linting +#### Before you start -You might have noticed already that we use ESLint to enforce a coding standard. Please run `yarn lint` before committing your changes to verify that the code style is correct. If not, you can use `yarn lint --fix` to fix most of the style changes. If there are still errors left, you must correct them manually. +Before you fix a bug, we recommend that you check whether **there's an issue that describes it**, as it's possible it's a documentation issue or that there is some context that would be helpful to know. -### Documentation +If you're working on a feature, then we ask that you **open a feature request issue first** to discuss with the maintainers whether the feature is desired - and the design of those features. This helps save time for both the maintainers and the contributors and means that features can be shipped faster. -If you are adding a new feature or refactoring or changing the behavior of Nuxt in any other manner, you'll likely want to document the changes. Please include any changes to the docs in the same PR. You don't have to write documentation up on the first commit (but please do so as soon as your pull request is mature enough). Make sure to make changes according to the [Documentation Guide](#documentation-guide). +For typo fixes, it's recommended to batch multiple typo fixes into one pull request to maintain a cleaner commit history. -### Final checklist +For bigger changes to Nuxt itself, we recommend that you first [create a Nuxt module](#createamodule) and implement the feature there. This allows for quick proof-of-concept. You can then [create an RFC](#makeanrfc) in the form of a discussion. As users adopt it and you gather feedback, it can then be refined and either added to Nuxt core or continue as a standalone module. -When submitting your PR, there is a simple template that you have to fill out. Please tick all appropriate "answers" in the checklists. +#### Commit conventions -Mainly, make sure your PR title adheres to [Conventional Commits guidelines](https://www.conventionalcommits.org/en/v1.0.0/), and do link the related issue (feature request or bug report) in the issue description. +We use [Conventional Commits](https://www.conventionalcommits.org/) for commit messages, which [allows a changelog to be auto-generated](https://github.com/unjs/changelogen) based on the commits. Please read the guide through if you aren't familiar with it already. -## Create a module +Note that `fix:` and `feat:` are for **actual code changes** (that might affect logic). For typo or document changes, use `docs:` or `chore:` instead: + +- ~~`fix: typo`~~ -> `docs: fix typo` + +If you are working in a project with a monorepo, like `nuxt/framework`, ensure that you specify the main scope of your commit in brackets. For example: `feat(nuxi): add 'do-magic' command`. + +#### Making the pull request + +If you don't know how to send a pull request, we recommend reading [the guide](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request). + +When sending a pull request, make sure your PR's title also follows the [Commit Convention](#commitconventions). + +If your PR fixes or resolves existing issues, please make sure you mention them in the PR description. + +It's ok to have multiple commits in a single PR; you don't need to rebase or force push for your changes as we will use `Squash and Merge` to squash the commits into one commit when merging. + +We do not add any commit hooks to allow for quick commits. But before you make a pull request, you should ensure that any lint/test scripts are passing. + +In general, please also make sure that there are no _unrelated_ changes in a PR. For example, if your editor has made any changes to whitespace or formatting elsewhere in a file that you edited, please revert these so it is more obvious what your PR changes. And please avoid including multiple unrelated features or fixes in a single PR. If it is possible to separate them, it is better to have multiple PRs to review and merge separately. + +#### Once you've made a pull request + +Once you've made a pull request, we'll do our best to review it promptly. + +If we assign it to a maintainer, then that means that person will take special care to review it and implement any changes that may be required. + +If we request changes on a PR, please ignore the red text! It doesn't mean we think it's a bad PR - it's just a way of easily telling the status of a list of pull requests at a glance. + +If we mark a PR as 'pending', that means we likely have another task to do in reviewing the PR - it's an internal note-to-self, and not a reflection on whether the PR is a good idea or not. + + + +### Create a module If you've built something with Nuxt that's cool, why not [extract it into a module](/guide/going-further/modules), so it can be shared with others? We have [many excellent modules already](https://modules.nuxtjs.org/), but there's always room for more. If you need help while building it, feel free to [check in with us](/community/getting-help). +### Make an RFC + +We highly recommend [creating a module](#createamodule) first to test out big new features and gain community adoption. + +If you have done this already, or it's not appropriate to create a new module, then please start by creating a new discussion. Make sure it explains your thinking as clearly as possible. Include code examples or function signatures for new APIs. Reference existing issues or pain points with examples. + +If we think this should be an RFC, we'll change the category to RFC and broadcast it more widely for feedback. + +An RFC will then move through the following stages: + +- `rfc: active` - currently open for comment +- `rfc: approved` - approved by the Nuxt team +- `rfc: shipped` - implemented +- `rfc: archived` - not approved, but archived for future reference + +### Conventions across ecosystem + +The following conventions are _required_ within the `nuxt/` organization and recommended for other maintainers in the ecosystem. + +#### Module conventions + +Modules should follow the [Nuxt module template](https://github.com/nuxt/starter/tree/module). See [module guide](/guide/going-further/modules) for more information. + +#### Use core `unjs/` libraries -## Documentation Guide +We recommend the following libraries which are used throughout the ecosystem: -Documentation is one of the essential parts of Nuxt. We aim to be an intuitive framework - and a big part of that is making sure that both the developer experience and the docs are perfect. 👌 +* [pathe](https://github.com/unjs/pathe) - universal path utilities (replacement for node `path`) +* [ufo](https://github.com/unjs/ufo) - URL parsing and joining utilities +* [unbuild](https://github.com/unjs/unbuild) - rollup-powered build system +* ... check out the rest of the [unjs/](https://github.com/unjs) organization for many more! -If you spot an area where we can improve documentation or error messages, please do open a PR - even if it's just to fix a typo! +#### Use ESM syntax and default to `type: module` -In this section, you will find: +Most of the Nuxt ecosystem can consume ESM directly. In general we advocate that you avoid using CJS-specific code, such as `__dirname` and `require` statements. You can [read more about ESM](/concepts/esm). -::list{type=success} +#### Package manager -- How to contribute and submit your changes. -- Tips to keep the documentation helpful and inclusive for everyone. +For libraries, we recommend `pnpm`. For modules, we still recommend `yarn` but we may well switch this recommendation to `pnpm` in future once we support plug and play mode with Nuxt itself. -:: +It is important to enable corepack to ensure you are on the same version of the package manager as the project. Corepack is built-in to new node versions for seamless package manager integration. -### Quick Edits +To enable it, run -If you spot a typo or want to rephrase a sentence, you can click on the **Edit this page on GitHub** link located after the content of every page. -Make the change directly in the GitHub interface and open a Pull Request. +```bash +corepack enable +``` -### Longer Edits +You only need to do this one time, after Node.js is installed on your computer. -The documentation content is inside the `docs/` directory of the [nuxt/framework repository](https://github.com/nuxt/framework) and written in markdown. +#### What's Corepack -To contribute, fork the repository and follow [these steps](#setup-documentation-website-in-local-environment) and start docs in development mode. +[Corepack](https://nodejs.org/api/corepack.html) makes sure you are using the correct version for package manager when you run corresponding commands. Projects might have `packageManager` field in their `package.json`. -After making your changes: +Under projects with configuration as shown below, corepack will install `v7.5.0` of `pnpm` (if you don't have it already) and use it to run your commands. + +```jsonc [package.json] +{ + "packageManager": "pnpm@7.5.0" +} +``` -- Lint the documentation with the `lint:docs` command. -- Open a Pull Request. Please make sure your PR title adheres to the [conventional commits](https://www.conventionalcommits.org/en/v1.0.0/) guidelines. +#### Use ESLint -### Linting docs +We use [ESLint](https://eslint.org/) for both linting and formatting with [`@nuxt/eslint-config`](https://github.com/nuxt/eslint-config). -Documentation is linted using [MarkdownLint](https://github.com/DavidAnson/markdownlint/) and [case police](https://github.com/antfu/case-police) to keep the documentation cohesive. +##### IDE Setup + +We recommend using [VS Code](https://code.visualstudio.com/) along with the [ESLint extension](https://marketplace.visualstudio.com/items?itemName=dbaeumer.vscode-eslint). If you would like, you can enable auto-fix and formatting when you save the code you are editing: + +```json [settings.json] +{ + "editor.codeActionsOnSave": { + "source.fixAll": false, + "source.fixAll.eslint": true + } +} +``` -### Writing tips +#### No Prettier + +Since ESLint is already configured to format the code, there is no need to duplicate the functionality with Prettier. To format the code, you can run `yarn lint --fix` or `pnpm lint --fix` or referring the [ESLint section](#eslint) for IDE Setup. + +If you have Prettier installed in your editor, we recommend you disable it when working on the project to avoid conflict. + +## Writing documentation + +Documentation is an essential part of Nuxt. We aim to be an intuitive framework - and a big part of that is making sure that both the developer experience and the docs are perfect across the ecosystem. 👌 + +Here are some tips that may help improve your documentation: - Avoid subjective words like _simply_, _just_, _obviously..._ when possible. @@ -103,32 +191,3 @@ Documentation is linted using [MarkdownLint](https://github.com/DavidAnson/markd ::alert{icon=✅} **Prefer:** "Nuxt will throw an error." :: - -## Set up your local development environment - -To contribute to Nuxt, you need to setup a local environment. - -1. [Fork](https://help.github.com/articles/fork-a-repo/) the [nuxt/framework repository](https://github.com/nuxt/framework) to your own GitHub account and then [clone](https://help.github.com/articles/cloning-a-repository/) it to your local device. - -1. Ensure using the latest Node.js (16.x) - -1. Enable [Corepack](https://github.com/nodejs/corepack) using `corepack enable` - -1. Run `yarn install` to install the dependencies. - - > If you are adding a dependency, please use `yarn add`. The `yarn.lock` file is the source of truth for all Nuxt dependencies. - -1. Run `yarn stub` to activate the passive development system - -1. Check out a branch where you can work and commit your changes: - -```bash -git checkout -b my-new-branch -``` - -### Setup documentation website in local environment - -1. Follow steps to setup [local development environment](#set-up-your-local-development-environment) -1. Change to the `docs/` directory using `cd docs/` -1. Install docs dependencies using `yarn install` -1. Start docs in development mode using `yarn dev` diff --git a/docs/content/5.community/4.framework-contribution.md b/docs/content/5.community/4.framework-contribution.md new file mode 100644 index 00000000000..71a08d6586b --- /dev/null +++ b/docs/content/5.community/4.framework-contribution.md @@ -0,0 +1,87 @@ +# nuxt/framework + +Once you've read the [general contribution guide](./contribution), here are some specific points to make about contributions to the `nuxt/framework` repository. + +## Using the playground + +While working on a PR, you will likely want to check if your changes are working correctly. + +You can modify the example app in `playground/`, and run it with `yarn dev`. Please make sure not to commit it to your branch, but it could be helpful to add some example code to your PR description. This can help reviewers and other Nuxt users understand the feature you've built in-depth. + +## Testing + +Every new feature should have a corresponding unit test (if possible). The `test` folder in this repository is currently a work in progress, but do your best to create a new test following the example of what's already there. + +Before creating a PR or marking it as ready-to-review, ensure that all tests pass by running `yarn test` locally. + +## Linting + +You might have noticed already that we use ESLint to enforce a coding standard. Please run `yarn lint` before committing your changes to verify that the code style is correct. If not, you can use `yarn lint --fix` to fix most of the style changes. If there are still errors left, you must correct them manually. + +### Documentation + +If you are adding a new feature or refactoring or changing the behavior of Nuxt in any other manner, you'll likely want to document the changes. Please include any changes to the docs in the same PR. You don't have to write documentation up on the first commit (but please do so as soon as your pull request is mature enough). Make sure to make changes according to the [Documentation Guide](./contribution#documentation-guide). + +### Final checklist + +When submitting your PR, there is a simple template that you have to fill out. Please tick all appropriate "answers" in the checklists. + +## Documentation Guide + +If you spot an area where we can improve documentation or error messages, please do open a PR - even if it's just to fix a typo! + +### Quick Edits + +If you spot a typo or want to rephrase a sentence, you can click on the **Edit this page on GitHub** link located after the content of every page. + +Make the change directly in the GitHub interface and open a Pull Request. + +### Longer Edits + +The documentation content is inside the `docs/` directory of the [nuxt/framework repository](https://github.com/nuxt/framework) and written in markdown. + +To contribute, fork the repository and follow [these steps](#setup-documentation-website-in-local-environment) and start docs in development mode. + +After making your changes: + +- Lint the documentation with the `lint:docs` command. +- Open a Pull Request. Please make sure your PR title adheres to the [conventional commits](https://www.conventionalcommits.org/en/v1.0.0/) guidelines. + +### Linting docs + +Documentation is linted using [MarkdownLint](https://github.com/DavidAnson/markdownlint/) and [case police](https://github.com/antfu/case-police) to keep the documentation cohesive. + +## Set up your local development environment + +To contribute to Nuxt, you need to setup a local environment. + +1. [Fork](https://help.github.com/articles/fork-a-repo/) the [nuxt/framework repository](https://github.com/nuxt/framework) to your own GitHub account and then [clone](https://help.github.com/articles/cloning-a-repository/) it to your local device. + +1. Ensure using the latest Node.js (16.x) + +1. Enable [Corepack](https://github.com/nodejs/corepack) using `corepack enable` + +1. Run `yarn install` to install the dependencies. + + > If you are adding a dependency, please use `yarn add`. The `yarn.lock` file is the source of truth for all Nuxt dependencies. + +1. Run `yarn stub` to activate the passive development system + +1. Check out a branch where you can work and commit your changes: + +```bash +git checkout -b my-new-branch +``` + +::js-doc{file=packages/nuxt/src/test.js function=useState} +:: + +::doc-link{file=packages/nuxt/src/test.js function=useState} +:: + +### Setup documentation website in local environment + +1. Follow steps to setup [local development environment](#set-up-your-local-development-environment) +1. Change to the `docs/` directory using `cd docs/` +1. Install docs dependencies using `yarn install` +1. Start docs in development mode using `yarn dev` diff --git a/docs/content/5.community/4.roadmap.md b/docs/content/5.community/5.roadmap.md similarity index 100% rename from docs/content/5.community/4.roadmap.md rename to docs/content/5.community/5.roadmap.md From e089102c66ddb58addd9c559dcd181d5c544346d Mon Sep 17 00:00:00 2001 From: Daniel Roe Date: Fri, 15 Jul 2022 14:16:31 +0100 Subject: [PATCH 3/8] style: lint --- docs/content/5.community/3.contribution.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/docs/content/5.community/3.contribution.md b/docs/content/5.community/3.contribution.md index ca37f045b8c..13bda7b4470 100644 --- a/docs/content/5.community/3.contribution.md +++ b/docs/content/5.community/3.contribution.md @@ -43,7 +43,7 @@ We use [Conventional Commits](https://www.conventionalcommits.org/) for commit m Note that `fix:` and `feat:` are for **actual code changes** (that might affect logic). For typo or document changes, use `docs:` or `chore:` instead: -- ~~`fix: typo`~~ -> `docs: fix typo` +* ~~`fix: typo`~~ -> `docs: fix typo` If you are working in a project with a monorepo, like `nuxt/framework`, ensure that you specify the main scope of your commit in brackets. For example: `feat(nuxi): add 'do-magic' command`. @@ -89,10 +89,10 @@ If we think this should be an RFC, we'll change the category to RFC and broadcas An RFC will then move through the following stages: -- `rfc: active` - currently open for comment -- `rfc: approved` - approved by the Nuxt team -- `rfc: shipped` - implemented -- `rfc: archived` - not approved, but archived for future reference +* `rfc: active` - currently open for comment +* `rfc: approved` - approved by the Nuxt team +* `rfc: shipped` - implemented +* `rfc: archived` - not approved, but archived for future reference ### Conventions across ecosystem @@ -170,7 +170,7 @@ Documentation is an essential part of Nuxt. We aim to be an intuitive framework Here are some tips that may help improve your documentation: -- Avoid subjective words like _simply_, _just_, _obviously..._ when possible. +* Avoid subjective words like _simply_, _just_, _obviously..._ when possible. Keep in mind your readers can have different backgrounds and experiences. Therefore, these words don't convey meaning and can be harmful. @@ -182,7 +182,7 @@ Here are some tips that may help improve your documentation: **Prefer:** "Make sure the function returns a [promise](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise)." :: -- Prefer [active voice](https://developers.google.com/tech-writing/one/active-voice). +* Prefer [active voice](https://developers.google.com/tech-writing/one/active-voice). ::alert{icon=❌} **Avoid:** "An error will be thrown by Nuxt." From be2a85e8fab410de2b8df91cdf51aaad0a7cdcd3 Mon Sep 17 00:00:00 2001 From: Daniel Roe Date: Thu, 21 Jul 2022 12:02:29 +0100 Subject: [PATCH 4/8] docs: implement suggestions from @pi0 --- docs/content/5.community/3.contribution.md | 37 ++++++++++++---------- 1 file changed, 20 insertions(+), 17 deletions(-) diff --git a/docs/content/5.community/3.contribution.md b/docs/content/5.community/3.contribution.md index 13bda7b4470..7d9821c5250 100644 --- a/docs/content/5.community/3.contribution.md +++ b/docs/content/5.community/3.contribution.md @@ -31,7 +31,7 @@ We always welcome pull requests! ❤️ Before you fix a bug, we recommend that you check whether **there's an issue that describes it**, as it's possible it's a documentation issue or that there is some context that would be helpful to know. -If you're working on a feature, then we ask that you **open a feature request issue first** to discuss with the maintainers whether the feature is desired - and the design of those features. This helps save time for both the maintainers and the contributors and means that features can be shipped faster. +If you're working on a feature, then we ask that you **open a feature request issue first** to discuss with the maintainers whether the feature is desired - and the design of those features. This helps save time for both the maintainers and the contributors and means that features can be shipped faster. The issue **should be confirmed** by a framework team member before building out a feature in a pull request. For typo fixes, it's recommended to batch multiple typo fixes into one pull request to maintain a cleaner commit history. @@ -59,7 +59,7 @@ It's ok to have multiple commits in a single PR; you don't need to rebase or for We do not add any commit hooks to allow for quick commits. But before you make a pull request, you should ensure that any lint/test scripts are passing. -In general, please also make sure that there are no _unrelated_ changes in a PR. For example, if your editor has made any changes to whitespace or formatting elsewhere in a file that you edited, please revert these so it is more obvious what your PR changes. And please avoid including multiple unrelated features or fixes in a single PR. If it is possible to separate them, it is better to have multiple PRs to review and merge separately. +In general, please also make sure that there are no _unrelated_ changes in a PR. For example, if your editor has made any changes to whitespace or formatting elsewhere in a file that you edited, please revert these so it is more obvious what your PR changes. And please avoid including multiple unrelated features or fixes in a single PR. If it is possible to separate them, it is better to have multiple PRs to review and merge separately. In general, a PR should do _one thing only_. #### Once you've made a pull request @@ -69,7 +69,7 @@ If we assign it to a maintainer, then that means that person will take special c If we request changes on a PR, please ignore the red text! It doesn't mean we think it's a bad PR - it's just a way of easily telling the status of a list of pull requests at a glance. -If we mark a PR as 'pending', that means we likely have another task to do in reviewing the PR - it's an internal note-to-self, and not a reflection on whether the PR is a good idea or not. +If we mark a PR as 'pending', that means we likely have another task to do in reviewing the PR - it's an internal note-to-self, and not necessarily a reflection on whether the PR is a good idea or not. We will do our best to explain via a comment the reason for the pending status. @@ -91,6 +91,7 @@ An RFC will then move through the following stages: * `rfc: active` - currently open for comment * `rfc: approved` - approved by the Nuxt team +* `rfc: ready to implement` - an issue has been created and assigned to implement * `rfc: shipped` - implemented * `rfc: archived` - not approved, but archived for future reference @@ -115,20 +116,6 @@ We recommend the following libraries which are used throughout the ecosystem: Most of the Nuxt ecosystem can consume ESM directly. In general we advocate that you avoid using CJS-specific code, such as `__dirname` and `require` statements. You can [read more about ESM](/concepts/esm). -#### Package manager - -For libraries, we recommend `pnpm`. For modules, we still recommend `yarn` but we may well switch this recommendation to `pnpm` in future once we support plug and play mode with Nuxt itself. - -It is important to enable corepack to ensure you are on the same version of the package manager as the project. Corepack is built-in to new node versions for seamless package manager integration. - -To enable it, run - -```bash -corepack enable -``` - -You only need to do this one time, after Node.js is installed on your computer. - #### What's Corepack [Corepack](https://nodejs.org/api/corepack.html) makes sure you are using the correct version for package manager when you run corresponding commands. Projects might have `packageManager` field in their `package.json`. @@ -164,6 +151,22 @@ Since ESLint is already configured to format the code, there is no need to dupli If you have Prettier installed in your editor, we recommend you disable it when working on the project to avoid conflict. +**Note**: [we are discussing](https://github.com/nuxt/eslint-config/issues/224) enabling prettier in future. + +#### Package manager + +For libraries, we recommend `pnpm`. For modules, we still recommend `yarn` but we may well switch this recommendation to `pnpm` in future once we support plug and play mode with Nuxt itself. + +It is important to enable corepack to ensure you are on the same version of the package manager as the project. Corepack is built-in to new node versions for seamless package manager integration. + +To enable it, run + +```bash +corepack enable +``` + +You only need to do this one time, after Node.js is installed on your computer. + ## Writing documentation Documentation is an essential part of Nuxt. We aim to be an intuitive framework - and a big part of that is making sure that both the developer experience and the docs are perfect across the ecosystem. 👌 From e5e8bd532fb76708b98eed4cc496812e68154525 Mon Sep 17 00:00:00 2001 From: Daniel Roe Date: Thu, 21 Jul 2022 12:57:42 +0100 Subject: [PATCH 5/8] feat: add mermaid flowcharts --- docs/content/5.community/3.contribution.md | 49 ++++++++++++++++++++-- 1 file changed, 46 insertions(+), 3 deletions(-) diff --git a/docs/content/5.community/3.contribution.md b/docs/content/5.community/3.contribution.md index 7d9821c5250..ad50e7b45a6 100644 --- a/docs/content/5.community/3.contribution.md +++ b/docs/content/5.community/3.contribution.md @@ -19,9 +19,37 @@ The Nuxt ecosystem includes many different projects and organizations. For examp Check out the issues and discussions for the project you want to help. For example, here are [the issues board](https://github.com/nuxt/framework/issues) and [discussions](https://github.com/nuxt/framework/discussions) for Nuxt 3. Helping other users, sharing workarounds, creating reproductions, or even poking into a bug a little bit and sharing your findings makes a huge difference. - +```mermaid +flowchart TD + A{Followed issue template?} + A-->|Yes| B{Is duplicate?} + A-->|No| C(Close and ask to follow template) + + B-->|Yes| D{Has proper reproduction?} + B-->|No| E(Close and point to duplicate) + + D-->|Yes| F{Is actually a bug?} + D-->|No| G(Label: 'needs reproduction'
close if no update < 3 days) + + F-->|Yes| H(1. Remove 'pending triage' label
2. Add 'bug' label
3. Add related package label if applicable
4. Add priority label) + F-->|No| I{Is the behavior intended?} + + I-->|Yes| J(Explain and close
point to docs if needed) + I-->|No| K(Keep open for discussion
remove 'pending triage' label and add 'discussion') + + H-->L{Does the behavior make Nuxt unusable?} + L-->|Yes| M{Does the bug affect the majority of users?} + L-->|No| N{Are there workarounds for the bug?} + + M-->|Yes| P5(p5: urgent) + M-->|No| P4(p4: important) + N-->|Yes| P2(p2: has workaround) + N-->|No| P3(p3: minor bug) +``` + +See [rendered flowchart](https://kroki.io/mermaid/svg/eNp9k09v4jAQxe_9FHNLOLTSAr2gqisoZWFLUbXayx5NPAkuiW35T1sU9rvv2AlJtodyQOCZ-b15z0leqvfswIyD38sroM-8XqmSDpGDsNYjOKx0yRx-_9vUr6_vz3_QnmFRbyxwr0uRfSrv1Bke0odSWQQmOTB7BKcgj-AOOLqKE4sOuKzXzII2SqMBg_SD-8wJJVv24sJ-HLC1EtIFerdJy1123FVYlGXOs7I8AYO9L1ri8kL8kW7ZHssZJBKR2__Uk7u9uc-ioMhBKvCakwzcwQQ4O9lWb9XprdNvN_ALK_WGkGiUXMgCnBGswATKoBOI4xuYcw4JbTM4nTSnBkNC5I5lRxpr6kGe6ehyX2Lonjbd2ghlhDs1baN-nWBtE9y7A8IeD-yNGoECo6WQUwixddNt_jN9_KC7ETJGGz0HmT5jldkYAoWEfNRPB6Gn9AlRA92epKs2wIXNvLWUYGCYr_JonpKQRj-UtLmuib-tlwo_uajYEWHnPxx46W1IpL3UbWfneTDmC2B5jpmLfyv22iSmcvAWjR3OBjO7em4wtNL3uzJHZpSX9GAEYy3vEt9zp_dym-rbGXhToHSjvhiAL9NUT2cgKq2MY5fyrp8dp3o8gwO9Ab3eoCkyJqmezKASkragDUb_AI6_NHc). ### Send a pull request @@ -71,7 +99,22 @@ If we request changes on a PR, please ignore the red text! It doesn't mean we th If we mark a PR as 'pending', that means we likely have another task to do in reviewing the PR - it's an internal note-to-self, and not necessarily a reflection on whether the PR is a good idea or not. We will do our best to explain via a comment the reason for the pending status. - +```mermaid +flowchart TD + A{What kind of PR is it?} + A---|Bug fix| B{Is it a 'strict fix'
i.e. fixes an obvious oversight
with no side effects?} + A---|Feature| C(* Discuss feature necessity
* Is this the best way to address the need?
* Review code quality
* Add feature labels
* Approve if you feel strongly that the feature is needed.) + A---|Documentation| D(* Review clarity and accuracy
* Look for opportunities to improve language)-->I + C-->E(Await input from Pooya)-->I + + B---|Yes| F(* Verify the fix locally
* Review code quality
* Require test case if applicable
* Request changes if necessary) + B---|No| G(Discuss the potential side effects of the fix, e.g.:
* Could it introduce implicit behavior changes in other cases?
* Does it introduce too many changes?) + G-->H(Add priority labels)-->E + + F-->I(Approve)-->J(Merge if approved by 2 or more team members) +``` + +[See rendered flowchart](https://kroki.io/mermaid/svg/eNqFk89vm1AMx-_9K3wrqZYcdpymRk3SdJ22qYqmVTuahwGrD0zfj6So7H-fHyTNehoHBH7G34-_NqWVg6nRBfi5uQC9bl4fawzwxG0BUsLDDtgDh-Wf6XQ-nw-rWEHJLwOsXu_TGSBc-uDYhBS-_Jy7a17QIr2QB2xB8j1L9CB7cp6rOqSUA4caWgHPBQGVJZng_1XZEoboaIB1dgUb9iZ6D-UUhJYMec-hT5WuQDFCzelGkJMPcMAeggAWhdO8Md4SFcspfUd7pgMYUeXniPatzk1RvElYzMn6Y7zrnMIDl9BL1BSyoB1LW1nVSX4lhdOXCpLEqFjMzu1sxMSG2oCBpR1gk50xLDolUKMKQGOiQ3PE-SbyBKU4kK4TF2LLgdVRbYybCchiW0WsaDafX9-PYmt9us1uDqhz4baLOhMnDTyI9DhljWmrxPSb_ABbJflFjst-aoJfwIpBa_v_mLWj58jabkiGG_SjPdh1lg3mls5J43mtpMquKdPs0PWzM8kPGeAuO005cXQS1C1G-25B0koeKT8ALarFp0lmLdEWMLasYymioWSRkmgopxp1_9yZQTdSi7gR2h93YiPk3xcIItBg25--W068d2rilyxtSue0aprctCrJ3dvJ3W0yOjtuTYp_zb6Tq04OpWgBeQ8fQbEaGU3EBhpqcv1DJp2Lvz5hNKI). ### Create a module From b7bee2f9e26f9fb5b1736a687c3284e87c0e1601 Mon Sep 17 00:00:00 2001 From: Daniel Roe Date: Thu, 21 Jul 2022 13:01:53 +0100 Subject: [PATCH 6/8] fix: remove mermaid diagrams pending upgrade to nuxt 3 --- docs/content/5.community/3.contribution.md | 47 +--------------------- 1 file changed, 2 insertions(+), 45 deletions(-) diff --git a/docs/content/5.community/3.contribution.md b/docs/content/5.community/3.contribution.md index ad50e7b45a6..32ea2eaf8f0 100644 --- a/docs/content/5.community/3.contribution.md +++ b/docs/content/5.community/3.contribution.md @@ -21,35 +21,7 @@ Check out the issues and discussions for the project you want to help. For examp ### Creating an issue -```mermaid -flowchart TD - A{Followed issue template?} - A-->|Yes| B{Is duplicate?} - A-->|No| C(Close and ask to follow template) - - B-->|Yes| D{Has proper reproduction?} - B-->|No| E(Close and point to duplicate) - - D-->|Yes| F{Is actually a bug?} - D-->|No| G(Label: 'needs reproduction'
close if no update < 3 days) - - F-->|Yes| H(1. Remove 'pending triage' label
2. Add 'bug' label
3. Add related package label if applicable
4. Add priority label) - F-->|No| I{Is the behavior intended?} - - I-->|Yes| J(Explain and close
point to docs if needed) - I-->|No| K(Keep open for discussion
remove 'pending triage' label and add 'discussion') - - H-->L{Does the behavior make Nuxt unusable?} - L-->|Yes| M{Does the bug affect the majority of users?} - L-->|No| N{Are there workarounds for the bug?} - - M-->|Yes| P5(p5: urgent) - M-->|No| P4(p4: important) - N-->|Yes| P2(p2: has workaround) - N-->|No| P3(p3: minor bug) -``` - -See [rendered flowchart](https://kroki.io/mermaid/svg/eNp9k09v4jAQxe_9FHNLOLTSAr2gqisoZWFLUbXayx5NPAkuiW35T1sU9rvv2AlJtodyQOCZ-b15z0leqvfswIyD38sroM-8XqmSDpGDsNYjOKx0yRx-_9vUr6_vz3_QnmFRbyxwr0uRfSrv1Bke0odSWQQmOTB7BKcgj-AOOLqKE4sOuKzXzII2SqMBg_SD-8wJJVv24sJ-HLC1EtIFerdJy1123FVYlGXOs7I8AYO9L1ri8kL8kW7ZHssZJBKR2__Uk7u9uc-ioMhBKvCakwzcwQQ4O9lWb9XprdNvN_ALK_WGkGiUXMgCnBGswATKoBOI4xuYcw4JbTM4nTSnBkNC5I5lRxpr6kGe6ehyX2Lonjbd2ghlhDs1baN-nWBtE9y7A8IeD-yNGoECo6WQUwixddNt_jN9_KC7ETJGGz0HmT5jldkYAoWEfNRPB6Gn9AlRA92epKs2wIXNvLWUYGCYr_JonpKQRj-UtLmuib-tlwo_uajYEWHnPxx46W1IpL3UbWfneTDmC2B5jpmLfyv22iSmcvAWjR3OBjO7em4wtNL3uzJHZpSX9GAEYy3vEt9zp_dym-rbGXhToHSjvhiAL9NUT2cgKq2MY5fyrp8dp3o8gwO9Ab3eoCkyJqmezKASkragDUb_AI6_NHc). +See [issue decision making flowchart](https://kroki.io/mermaid/svg/eNp9k09v4jAQxe_9FHNLOLTSAr2gqisoZWFLUbXayx5NPAkuiW35T1sU9rvv2AlJtodyQOCZ-b15z0leqvfswIyD38sroM-8XqmSDpGDsNYjOKx0yRx-_9vUr6_vz3_QnmFRbyxwr0uRfSrv1Bke0odSWQQmOTB7BKcgj-AOOLqKE4sOuKzXzII2SqMBg_SD-8wJJVv24sJ-HLC1EtIFerdJy1123FVYlGXOs7I8AYO9L1ri8kL8kW7ZHssZJBKR2__Uk7u9uc-ioMhBKvCakwzcwQQ4O9lWb9XprdNvN_ALK_WGkGiUXMgCnBGswATKoBOI4xuYcw4JbTM4nTSnBkNC5I5lRxpr6kGe6ehyX2Lonjbd2ghlhDs1baN-nWBtE9y7A8IeD-yNGoECo6WQUwixddNt_jN9_KC7ETJGGz0HmT5jldkYAoWEfNRPB6Gn9AlRA92epKs2wIXNvLWUYGCYr_JonpKQRj-UtLmuib-tlwo_uajYEWHnPxx46W1IpL3UbWfneTDmC2B5jpmLfyv22iSmcvAWjR3OBjO7em4wtNL3uzJHZpSX9GAEYy3vEt9zp_dym-rbGXhToHSjvhiAL9NUT2cgKq2MY5fyrp8dp3o8gwO9Ab3eoCkyJqmezKASkragDUb_AI6_NHc). ### Send a pull request @@ -99,22 +71,7 @@ If we request changes on a PR, please ignore the red text! It doesn't mean we th If we mark a PR as 'pending', that means we likely have another task to do in reviewing the PR - it's an internal note-to-self, and not necessarily a reflection on whether the PR is a good idea or not. We will do our best to explain via a comment the reason for the pending status. -```mermaid -flowchart TD - A{What kind of PR is it?} - A---|Bug fix| B{Is it a 'strict fix'
i.e. fixes an obvious oversight
with no side effects?} - A---|Feature| C(* Discuss feature necessity
* Is this the best way to address the need?
* Review code quality
* Add feature labels
* Approve if you feel strongly that the feature is needed.) - A---|Documentation| D(* Review clarity and accuracy
* Look for opportunities to improve language)-->I - C-->E(Await input from Pooya)-->I - - B---|Yes| F(* Verify the fix locally
* Review code quality
* Require test case if applicable
* Request changes if necessary) - B---|No| G(Discuss the potential side effects of the fix, e.g.:
* Could it introduce implicit behavior changes in other cases?
* Does it introduce too many changes?) - G-->H(Add priority labels)-->E - - F-->I(Approve)-->J(Merge if approved by 2 or more team members) -``` - -[See rendered flowchart](https://kroki.io/mermaid/svg/eNqFk89vm1AMx-_9K3wrqZYcdpymRk3SdJ22qYqmVTuahwGrD0zfj6So7H-fHyTNehoHBH7G34-_NqWVg6nRBfi5uQC9bl4fawzwxG0BUsLDDtgDh-Wf6XQ-nw-rWEHJLwOsXu_TGSBc-uDYhBS-_Jy7a17QIr2QB2xB8j1L9CB7cp6rOqSUA4caWgHPBQGVJZng_1XZEoboaIB1dgUb9iZ6D-UUhJYMec-hT5WuQDFCzelGkJMPcMAeggAWhdO8Md4SFcspfUd7pgMYUeXniPatzk1RvElYzMn6Y7zrnMIDl9BL1BSyoB1LW1nVSX4lhdOXCpLEqFjMzu1sxMSG2oCBpR1gk50xLDolUKMKQGOiQ3PE-SbyBKU4kK4TF2LLgdVRbYybCchiW0WsaDafX9-PYmt9us1uDqhz4baLOhMnDTyI9DhljWmrxPSb_ABbJflFjst-aoJfwIpBa_v_mLWj58jabkiGG_SjPdh1lg3mls5J43mtpMquKdPs0PWzM8kPGeAuO005cXQS1C1G-25B0koeKT8ALarFp0lmLdEWMLasYymioWSRkmgopxp1_9yZQTdSi7gR2h93YiPk3xcIItBg25--W068d2rilyxtSue0aprctCrJ3dvJ3W0yOjtuTYp_zb6Tq04OpWgBeQ8fQbEaGU3EBhpqcv1DJp2Lvz5hNKI). +[See PR decision making flowchart](https://kroki.io/mermaid/svg/eNqFk89vm1AMx-_9K3wrqZYcdpymRk3SdJ22qYqmVTuahwGrD0zfj6So7H-fHyTNehoHBH7G34-_NqWVg6nRBfi5uQC9bl4fawzwxG0BUsLDDtgDh-Wf6XQ-nw-rWEHJLwOsXu_TGSBc-uDYhBS-_Jy7a17QIr2QB2xB8j1L9CB7cp6rOqSUA4caWgHPBQGVJZng_1XZEoboaIB1dgUb9iZ6D-UUhJYMec-hT5WuQDFCzelGkJMPcMAeggAWhdO8Md4SFcspfUd7pgMYUeXniPatzk1RvElYzMn6Y7zrnMIDl9BL1BSyoB1LW1nVSX4lhdOXCpLEqFjMzu1sxMSG2oCBpR1gk50xLDolUKMKQGOiQ3PE-SbyBKU4kK4TF2LLgdVRbYybCchiW0WsaDafX9-PYmt9us1uDqhz4baLOhMnDTyI9DhljWmrxPSb_ABbJflFjst-aoJfwIpBa_v_mLWj58jabkiGG_SjPdh1lg3mls5J43mtpMquKdPs0PWzM8kPGeAuO005cXQS1C1G-25B0koeKT8ALarFp0lmLdEWMLasYymioWSRkmgopxp1_9yZQTdSi7gR2h93YiPk3xcIItBg25--W068d2rilyxtSue0aprctCrJ3dvJ3W0yOjtuTYp_zb6Tq04OpWgBeQ8fQbEaGU3EBhpqcv1DJp2Lvz5hNKI). ### Create a module From bab24c821fda8f49c0ee8dd41a67baeba11ee97a Mon Sep 17 00:00:00 2001 From: Daniel Roe Date: Thu, 21 Jul 2022 13:08:40 +0100 Subject: [PATCH 7/8] style: fix fragment links --- docs/content/5.community/3.contribution.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/content/5.community/3.contribution.md b/docs/content/5.community/3.contribution.md index 32ea2eaf8f0..866d3375b68 100644 --- a/docs/content/5.community/3.contribution.md +++ b/docs/content/5.community/3.contribution.md @@ -35,7 +35,7 @@ If you're working on a feature, then we ask that you **open a feature request is For typo fixes, it's recommended to batch multiple typo fixes into one pull request to maintain a cleaner commit history. -For bigger changes to Nuxt itself, we recommend that you first [create a Nuxt module](#createamodule) and implement the feature there. This allows for quick proof-of-concept. You can then [create an RFC](#makeanrfc) in the form of a discussion. As users adopt it and you gather feedback, it can then be refined and either added to Nuxt core or continue as a standalone module. +For bigger changes to Nuxt itself, we recommend that you first [create a Nuxt module](#create-a-module) and implement the feature there. This allows for quick proof-of-concept. You can then [create an RFC](#make-an-rfc) in the form of a discussion. As users adopt it and you gather feedback, it can then be refined and either added to Nuxt core or continue as a standalone module. #### Commit conventions @@ -51,7 +51,7 @@ If you are working in a project with a monorepo, like `nuxt/framework`, ensure t If you don't know how to send a pull request, we recommend reading [the guide](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request). -When sending a pull request, make sure your PR's title also follows the [Commit Convention](#commitconventions). +When sending a pull request, make sure your PR's title also follows the [Commit Convention](#commit-conventions). If your PR fixes or resolves existing issues, please make sure you mention them in the PR description. @@ -81,7 +81,7 @@ If you need help while building it, feel free to [check in with us](/community/g ### Make an RFC -We highly recommend [creating a module](#createamodule) first to test out big new features and gain community adoption. +We highly recommend [creating a module](#create-a-module) first to test out big new features and gain community adoption. If you have done this already, or it's not appropriate to create a new module, then please start by creating a new discussion. Make sure it explains your thinking as clearly as possible. Include code examples or function signatures for new APIs. Reference existing issues or pain points with examples. @@ -147,7 +147,7 @@ We recommend using [VS Code](https://code.visualstudio.com/) along with the [ESL #### No Prettier -Since ESLint is already configured to format the code, there is no need to duplicate the functionality with Prettier. To format the code, you can run `yarn lint --fix` or `pnpm lint --fix` or referring the [ESLint section](#eslint) for IDE Setup. +Since ESLint is already configured to format the code, there is no need to duplicate the functionality with Prettier. To format the code, you can run `yarn lint --fix` or `pnpm lint --fix` or referring the [ESLint section](#use-eslint) for IDE Setup. If you have Prettier installed in your editor, we recommend you disable it when working on the project to avoid conflict. From d7bcdc1128790c35e943196e68553f73c459eda6 Mon Sep 17 00:00:00 2001 From: Daniel Roe Date: Fri, 22 Jul 2022 09:21:41 +0100 Subject: [PATCH 8/8] docs: update flowchart --- docs/content/5.community/3.contribution.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/content/5.community/3.contribution.md b/docs/content/5.community/3.contribution.md index 866d3375b68..f61f1c59f8b 100644 --- a/docs/content/5.community/3.contribution.md +++ b/docs/content/5.community/3.contribution.md @@ -21,7 +21,7 @@ Check out the issues and discussions for the project you want to help. For examp ### Creating an issue -See [issue decision making flowchart](https://kroki.io/mermaid/svg/eNp9k09v4jAQxe_9FHNLOLTSAr2gqisoZWFLUbXayx5NPAkuiW35T1sU9rvv2AlJtodyQOCZ-b15z0leqvfswIyD38sroM-8XqmSDpGDsNYjOKx0yRx-_9vUr6_vz3_QnmFRbyxwr0uRfSrv1Bke0odSWQQmOTB7BKcgj-AOOLqKE4sOuKzXzII2SqMBg_SD-8wJJVv24sJ-HLC1EtIFerdJy1123FVYlGXOs7I8AYO9L1ri8kL8kW7ZHssZJBKR2__Uk7u9uc-ioMhBKvCakwzcwQQ4O9lWb9XprdNvN_ALK_WGkGiUXMgCnBGswATKoBOI4xuYcw4JbTM4nTSnBkNC5I5lRxpr6kGe6ehyX2Lonjbd2ghlhDs1baN-nWBtE9y7A8IeD-yNGoECo6WQUwixddNt_jN9_KC7ETJGGz0HmT5jldkYAoWEfNRPB6Gn9AlRA92epKs2wIXNvLWUYGCYr_JonpKQRj-UtLmuib-tlwo_uajYEWHnPxx46W1IpL3UbWfneTDmC2B5jpmLfyv22iSmcvAWjR3OBjO7em4wtNL3uzJHZpSX9GAEYy3vEt9zp_dym-rbGXhToHSjvhiAL9NUT2cgKq2MY5fyrp8dp3o8gwO9Ab3eoCkyJqmezKASkragDUb_AI6_NHc). +See [issue decision making flowchart](https://kroki.io/mermaid/svg/eNp9Uktv2kAQvudXzM32IZEK5GJFqUgIhYagqOqlx7V3bLasd1f7SIKg_72ztrFpDuVgiZ35HvPNVFK_lztmPfxcXAH95sellvSIHIRzAcFjYyTz-PVPV7--vj_9QneCh-PaAQ9GivJTeatP8Jg-Su0QmOLA3B68hqolHgizqxbxMBA-XUCMFspH0CCQjd2Rf3FcMQeNUKJhEiwaq3kovdCKnLSti4F4GZ2y0gcm5QEYFKHu7S7OdN_SDStQ5pAoRO7-IUzuCnvfiHrnoWwNigqUhmA42YI7mAJnB9ePsxxUV-mXG_iBjX5DSAwqLlQN3gpWYwIyqkXeyQ3MOYeEPF28TrtXizEoSoOVe4J19SjPTJtKITF2z7puY4W2wh-6tmy0Ewdcxwz8DqHAHXujRqCAyRTyc17rwfn39OmDViRUu4p25igz7kSXrg2BokKejego9Jw-IxrQNDFt3AIXrgzOUY6Rw_4vj-5YYhojKOlzXRH_5rjQ-GmKhu0RtuHDQ1DBxUT61W6GcV4uYKEGVlVY-vZvw353iekKgkPrLrFxmO1xbjG20vdd2z2zOig6jzhYz3eO72XQe71NzW0OwdaofDYWI-HrLDWzHERjtPXsXN6O2ElqJjns6LZHvYumlmOammkeb59ckIPsL5zkNv8). ### Send a pull request