mirror of
https://github.com/supabase/supabase.git
synced 2026-10-05 09:25:06 +03:00
Miranda Limonczenko
7ce4ee53ae
Closes [DOCS-1289](https://linear.app/supabase/issue/DOCS-1289/get-the-linter-to-fix-what-it-flags-or-retirereplace-the-linter) Stacked on #50600, which points contributors at the authoring skills. Merge that one first. ## Problem Contributors experienced friction with the linter. They felt nickle and dimed for tiny nits and felt detracted from the work itself. PRs would become noisy with tiny one-word suggestions. Additionally, our homegrown linter is not very intelligent, causing frequent overrides. ## Solution This removes the linter entirely in favor of directing contributors to use SKILLS instead. The removal entails... - **CI.** Delete the three `docs_lint` workflows: the PR check, the external-PR comment companion, and the nightly `--fix` bot. Drop the stale `zizmor.yml` ignore entry for the deleted workflow. - **Tooling.** Delete `supa-mdx-lint.config.toml` and the 14 rule files. Drop the `lint:mdx` script and the `@supabase/supa-mdx-lint` dependency from docs, learn, and ui-library, and regenerate the lockfile. - **Content.** Remove the 181 directives. A separate commit carries Prettier's reformatting of the tables and blank lines those comments had suppressed, so the deletion commit stays readable. No prose changes. - **Style guide.** The word list states each rule directly instead of describing what the linter flagged. Every term survives, including the phrase groups that mirrored `Rule004ExcludeWords`. - **Skills.** `write-the-docs`, `edit-the-docs`, and `review-the-docs` drop `pnpm lint:mdx` from their self-review commands and check the word list directly. `ask-the-docs`'s CI reference drops both workflows. ## Manual testing 1. Run `git grep -i supa-mdx-lint -- . ':!pnpm-lock.yaml'`. No matches. 2. Run `pnpm install --frozen-lockfile --lockfile-only`. It passes, so the lockfile matches the three trimmed manifests. 3. Run `git diff master...HEAD --name-only --diff-filter=ACMR | grep -E '\.(md|mdx)$' | xargs npx prettier --config prettier.config.mjs --check`. All changed markdown passes. 4. Open the [reformatted filter table](https://docs-git-docs-retire-mdx-linter-supabase.vercel.app/docs/guides/observability/logs#filter-events) on the preview and compare it with [production](https://supabase.com/docs/guides/observability/logs#filter-events). The table renders the same. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Documentation guidance now uses manual prose and terminology review with the shared word list. * Clarified storage configuration and common Realtime channel mistakes. * Improved table formatting, text wrapping, and selected reference links. * Updated documentation authoring and review guidance. * **Chores** * Retired automated MDX linting from workflows and local validation commands. * Removed lint-suppression markers throughout documentation without changing instructions. * Added targeted documentation review guidance for pull requests. <!-- end of auto-generated comment: release notes by coderabbit.ai -->
35 lines
1.5 KiB
Plaintext
35 lines
1.5 KiB
Plaintext
---
|
|
title: A DESCRIPTIVE TITLE
|
|
subtitle: A DESCRIPTIVE SUBTITLE
|
|
---
|
|
|
|
{/* Use this template to document Auth Flows. These should be how-to guides, walking the reader through the process of (1) enabling the feature and (2) triggering the flow from their code. */}
|
|
|
|
A brief description of what this flow does. Don't get into details: if the concepts require a lot of explanation, make a separate page under Concepts.
|
|
|
|
## Enabling WHATEVER_FLOW
|
|
|
|
If the feature is default on, say so. If the feature needs to be turned on in the Dashboard, say how. If the feature can be turned on in self-hosted, say how.
|
|
|
|
If configuration is required, say how. If configuration is extensive, you can link to a separate explanation under Configuration.
|
|
|
|
## Using the flow (1)
|
|
|
|
Step-by-step instructions on how to use the flow. This assumes configuration is already done, and just contains the application code needed by the developer.
|
|
|
|
This first section should contain the most basic example of the flow (e.g., a client-side sign in with password).
|
|
|
|
If multiple steps are required, use an ordered list. Always include code examples.
|
|
|
|
## Using the flow (2)
|
|
|
|
Step-by-step instructions on how to use the flow. This assumes configuration is already done, and just contains the application code needed by the developer.
|
|
|
|
This can contain another related flow (e.g., change password, or PKCE version of flow 1).
|
|
|
|
If multiple steps are required, use an ordered list. Always include code examples.
|
|
|
|
## Resources
|
|
|
|
{/* Optional section containing a list of links to learn more. */}
|