mirror of
https://github.com/prdlk/leetcode.git
synced 2026-09-17 07:26:27 +00:00
66 lines
3.1 KiB
Markdown
66 lines
3.1 KiB
Markdown
---
|
|
description: Sync work/ leetcode solutions into docs/solutions/ pages (gold standard format)
|
|
---
|
|
|
|
Sync every leetcode solution under `work/` into a docs page under `docs/reference/`, formatted exactly like the gold standard `docs/solutions/01-reverse-string.mdx`. Extra focus (optional): $@
|
|
|
|
## Inventory
|
|
|
|
1. Glob `work/**/*.js`. Each filename is `<number>.<kebab-slug>.js`; the directory path is `work/<Difficulty>/<Category>/`.
|
|
2. Glob `docs/solutions/*.mdx`. A solution is already ported when a page's frontmatter title starts with the same leetcode number (`title: '<number>. …'`). Numeric filename prefixes (`01-`, `02-`, …) define sidebar order — never renumber existing pages.
|
|
3. Build the todo list: one task per unported solution, plus one task per already-ported page whose `## Answer` code block no longer matches its `work/` source verbatim (update just the code block in that case).
|
|
|
|
## Target path
|
|
|
|
`docs/solutions/<NN>-<kebab-slug>.mdx` where `<NN>` is the next unused two-digit prefix (continue from the highest existing one, in ascending leetcode-number order for the new batch) and `<kebab-slug>` is the slug from the work filename.
|
|
|
|
## Page format — copy the gold standard exactly
|
|
|
|
Every work file has a header comment block containing the problem statement, examples, constraints, and any follow-up. Transform it into:
|
|
|
|
````mdx
|
|
---
|
|
title: '<number>. <Problem Name>'
|
|
description: <first sentence of the problem statement, no trailing period>
|
|
sidebar:
|
|
badge: '<Difficulty>'
|
|
---
|
|
|
|
<Badge variant="accent"><Topic></Badge>
|
|
|
|
::::warning
|
|
<the follow-up or special requirement, verbatim>
|
|
::::
|
|
|
|
### Example 1:
|
|
- Input: `<input>`
|
|
- Output: `<output>`
|
|
- Explanation: <explanation with array/value literals wrapped in backticks>
|
|
|
|
### Constraints:
|
|
|
|
- `<constraint>` (inline code; keep plain prose like "nums is sorted…" with only identifiers in backticks)
|
|
|
|
## Answer
|
|
|
|
```js
|
|
<the JSDoc comment and function from the work file, byte-for-byte verbatim — do not reformat, rename, or "improve" the code>
|
|
```
|
|
````
|
|
|
|
Rules:
|
|
|
|
- `<Topic>`: the problem's pattern category from the curriculum tables in `README.md` (e.g. "Two Pointers", "Hash-Based Lookup" → use "Hash Table", "Sliding Window", "Prefix Sum"). Fall back to the `work/` subdirectory name if the problem isn't in the README.
|
|
- `::::warning`: only when the statement has a follow-up, in-place requirement, or similar special constraint. Omit the block entirely otherwise.
|
|
- One `### Example N:` section per example in the header comment; include the Explanation bullet only when the source has one.
|
|
- Exponents stay caret-style in inline code (`10^4`), matching the source comments.
|
|
- Do NOT copy the header comment block into the page — only the JSDoc + function go in the code fence.
|
|
|
|
## Verify
|
|
|
|
1. `bunx blume build --isolated` must succeed with no new warnings; confirm each new route generated (`/solutions/<slug>`).
|
|
2. Spot-check one new page's built HTML for the badge, callout (when present), and solution code.
|
|
3. `rm -rf .blume-verify` when done.
|
|
|
|
Report a table: work file → docs page → created / updated / skipped (already in sync).
|