|
| 1 | +/* |
| 2 | + * Nextra <Tabs> blocks mix JSX tags with Markdown children. That boundary is |
| 3 | + * fragile: MDX may accept a Tabs block where the tags, fenced code blocks, and |
| 4 | + * following prose are adjacent, but Prettier will not necessarily recover the |
| 5 | + * safer block structure for us. |
| 6 | + * |
| 7 | + * For example, this input has the unsafe adjacency we want to reject. The |
| 8 | + * fenced JavaScript is intentionally unformatted so the Prettier behavior is |
| 9 | + * visible: |
| 10 | + * |
| 11 | + * <Tabs items={["Code"]}> |
| 12 | + * <Tabs.Tab> |
| 13 | + * ```js |
| 14 | + * const value={a:1}; |
| 15 | + * ``` |
| 16 | + * </Tabs.Tab></Tabs> |
| 17 | + * Next paragraph. |
| 18 | + * |
| 19 | + * Running `prettier --parser mdx` on that input produces this: |
| 20 | + * |
| 21 | + * <Tabs items={["Code"]}> |
| 22 | + * <Tabs.Tab> |
| 23 | + * ```js |
| 24 | + * const value={a:1}; |
| 25 | + * ``` |
| 26 | + * </Tabs.Tab></Tabs> |
| 27 | + * Next paragraph. |
| 28 | + * |
| 29 | + * The formatting problem is that Prettier does not treat the fenced block as a |
| 30 | + * normal Markdown code fence in a Tabs panel: the JavaScript stays unformatted, |
| 31 | + * the fence remains glued to <Tabs.Tab>, the closing tags remain collapsed, and |
| 32 | + * the next paragraph remains glued to </Tabs>. |
| 33 | + * |
| 34 | + * With clear JSX/Markdown boundaries, Prettier formats the fenced JavaScript and |
| 35 | + * keeps the Tabs block readable: |
| 36 | + * |
| 37 | + * <Tabs items={["Code"]}> |
| 38 | + * <Tabs.Tab> |
| 39 | + * |
| 40 | + * ```js |
| 41 | + * const value = { a: 1 }; |
| 42 | + * ``` |
| 43 | + * |
| 44 | + * </Tabs.Tab> |
| 45 | + * </Tabs> |
| 46 | + * |
| 47 | + * Next paragraph. |
| 48 | + * |
| 49 | + * This is intentionally not a general Markdown style rule. It only protects the |
| 50 | + * Nextra Tabs shapes that can survive Prettier in a bad form. |
| 51 | + */ |
| 52 | + |
| 53 | +const mdxSourceByFilename = new Map(); |
| 54 | +const mdxTabsSpacingProcessor = { |
| 55 | + meta: { |
| 56 | + name: 'internal-rules/mdx-tabs-spacing', |
| 57 | + }, |
| 58 | + preprocess(text, filename) { |
| 59 | + mdxSourceByFilename.set(filename, text); |
| 60 | + return ['']; |
| 61 | + }, |
| 62 | + postprocess(messageLists, filename) { |
| 63 | + const source = mdxSourceByFilename.get(filename); |
| 64 | + mdxSourceByFilename.delete(filename); |
| 65 | + |
| 66 | + return [ |
| 67 | + ...messageLists.flat(), |
| 68 | + ...(source == null ? [] : checkMdxTabsSpacing(source)), |
| 69 | + ]; |
| 70 | + }, |
| 71 | + supportsAutofix: false, |
| 72 | +}; |
| 73 | + |
| 74 | +function checkMdxTabsSpacing(source) { |
| 75 | + const lines = source.split(/\r?\n/u); |
| 76 | + const messages = []; |
| 77 | + |
| 78 | + for (let index = 0; index < lines.length; index++) { |
| 79 | + const line = lines[index]; |
| 80 | + const trimmed = line.trim(); |
| 81 | + |
| 82 | + // Prettier can collapse or preserve this one-line close in a way that makes |
| 83 | + // later conflict resolution hard to read and easy to break again. Keeping the |
| 84 | + // component close and container close on separate lines gives Markdown a |
| 85 | + // clear block boundary after the final tab panel. |
| 86 | + if (/<\/Tabs\.Tab>\s*<\/Tabs>/.test(line)) { |
| 87 | + report( |
| 88 | + messages, |
| 89 | + lines, |
| 90 | + index, |
| 91 | + line.indexOf('</Tabs.Tab>'), |
| 92 | + 'Close </Tabs.Tab> and </Tabs> on separate lines.', |
| 93 | + ); |
| 94 | + } |
| 95 | + |
| 96 | + // A <Tabs> block should start as its own Markdown block. If it is glued to |
| 97 | + // the previous paragraph/list item, MDX still accepts the file, but Prettier |
| 98 | + // can treat the JSX and surrounding Markdown as one construct and preserve |
| 99 | + // surprising layout. |
| 100 | + if (isTabsOpen(trimmed) && index > 0 && !isBlank(lines[index - 1])) { |
| 101 | + report( |
| 102 | + messages, |
| 103 | + lines, |
| 104 | + index, |
| 105 | + line.indexOf('<Tabs'), |
| 106 | + 'Add a blank line before <Tabs> blocks.', |
| 107 | + ); |
| 108 | + } |
| 109 | + |
| 110 | + // The closing </Tabs> needs the same protection in the other direction. The |
| 111 | + // bug this guard was added for was exactly a closing Tabs block followed by |
| 112 | + // prose with no blank line; that made the following paragraph part of the |
| 113 | + // same MDX flow and led Prettier to keep an unsafe shape. |
| 114 | + if ( |
| 115 | + isTabsClose(trimmed) && |
| 116 | + index < lines.length - 1 && |
| 117 | + !isBlank(lines[index + 1]) |
| 118 | + ) { |
| 119 | + report( |
| 120 | + messages, |
| 121 | + lines, |
| 122 | + index, |
| 123 | + line.indexOf('</Tabs>'), |
| 124 | + 'Add a blank line after </Tabs> blocks.', |
| 125 | + ); |
| 126 | + } |
| 127 | + |
| 128 | + // Fenced code inside a JSX child is only unambiguously Markdown when there is |
| 129 | + // a blank line after <Tabs.Tab>. Without it, MDX/Prettier can handle the |
| 130 | + // fence as adjacent JSX text, and later formatting may not restore the tab |
| 131 | + // panel structure we expect. |
| 132 | + if ( |
| 133 | + isTabsTabOpen(trimmed) && |
| 134 | + index < lines.length - 1 && |
| 135 | + isCodeFence(lines[index + 1]) |
| 136 | + ) { |
| 137 | + report( |
| 138 | + messages, |
| 139 | + lines, |
| 140 | + index, |
| 141 | + line.indexOf('<Tabs.Tab>'), |
| 142 | + 'Add a blank line between <Tabs.Tab> and fenced code blocks.', |
| 143 | + ); |
| 144 | + } |
| 145 | + |
| 146 | + // Likewise, the end of a fenced code block should be separated from the |
| 147 | + // closing tab panel tag. This keeps the fence close from being visually and |
| 148 | + // syntactically glued to JSX during conflict resolution and Prettier passes. |
| 149 | + if ( |
| 150 | + isCodeFence(line) && |
| 151 | + index < lines.length - 1 && |
| 152 | + isTabsTabClose(lines[index + 1].trim()) |
| 153 | + ) { |
| 154 | + report( |
| 155 | + messages, |
| 156 | + lines, |
| 157 | + index, |
| 158 | + firstNonWhitespaceIndex(line), |
| 159 | + 'Add a blank line between fenced code blocks and </Tabs.Tab>.', |
| 160 | + ); |
| 161 | + } |
| 162 | + } |
| 163 | + |
| 164 | + return messages; |
| 165 | +} |
| 166 | + |
| 167 | +function report(messages, lines, lineIndex, columnIndex, message) { |
| 168 | + messages.push({ |
| 169 | + ruleId: 'internal-rules/mdx-tabs-spacing', |
| 170 | + severity: 2, |
| 171 | + message, |
| 172 | + line: lineIndex + 1, |
| 173 | + column: columnIndex + 1, |
| 174 | + endLine: lineIndex + 1, |
| 175 | + endColumn: lines[lineIndex].length + 1, |
| 176 | + }); |
| 177 | +} |
| 178 | + |
| 179 | +function isTabsOpen(trimmedLine) { |
| 180 | + return /^<Tabs(?:\s|>)/u.test(trimmedLine); |
| 181 | +} |
| 182 | + |
| 183 | +function isTabsClose(trimmedLine) { |
| 184 | + return trimmedLine === '</Tabs>'; |
| 185 | +} |
| 186 | + |
| 187 | +function isTabsTabOpen(trimmedLine) { |
| 188 | + return trimmedLine === '<Tabs.Tab>'; |
| 189 | +} |
| 190 | + |
| 191 | +function isTabsTabClose(trimmedLine) { |
| 192 | + return trimmedLine === '</Tabs.Tab>'; |
| 193 | +} |
| 194 | + |
| 195 | +function isCodeFence(line) { |
| 196 | + return /^`{3,}/u.test(line.trim()); |
| 197 | +} |
| 198 | + |
| 199 | +function isBlank(line) { |
| 200 | + return line.trim() === ''; |
| 201 | +} |
| 202 | + |
| 203 | +function firstNonWhitespaceIndex(line) { |
| 204 | + const match = /\S/u.exec(line); |
| 205 | + return match == null ? 0 : match.index; |
| 206 | +} |
| 207 | + |
| 208 | +export { mdxTabsSpacingProcessor }; |
0 commit comments