Summary by CodeRabbit

• Bug Fixes

  • Improved SQL formatting for numeric property access, preventing tokens from merging incorrectly.
  • Preserved comments and ensured repeated formatting produces consistent results.

• Tests

  • Added regression coverage for MySQL formatting involving numeric property access and comments.

Walkthrough

The formatter now inserts a space between a bare integer literal and a following leading-dot token. A MySQL regression test verifies formatting and idempotence for numeric property access with a comment.

Changes

Integer property-access formatting

Estimated code review effort: 2 (Simple) | ~10 minutes

Merge Risk: ⚪ Minimal · up to 7c803

The change is localized to preventing a property-access dot from being joined to a bare integer literal, with focused MySQL coverage. No actionable merge-blocking risk remains beyond normal checks and review.

Possibly related PRs

• sql-formatter-org/sql-formatter#956: Both changes update Layout.add() to prevent token sequences from being misinterpreted, but they handle different token patterns.

Suggested reviewers: nene, sarathfrancis90

• Create PR with unit tests

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

• X
• Mastodon
• Reddit
• LinkedIn

Comment @coderabbitai help to get the list of available commands.

Could you provide a full executable example of the code. When I simply try running the following in MySQL:

SELECT 1 . /*x*/ 5e

I just get an error.

Is the number 1 a table name or alias? I tried that, but wasn't able to use plain number as a table name. So it must be something else, but I have no idea.

You're right that it isn't runnable MySQL — I should have led with that. It's not a query, it's a minimal token sequence. The formatter tokenizes rather than validates, so it still lays it out, and the point is only that its own output isn't stable.

On 15.8.2, formatting it twice gives two different results:

const { format } = require('sql-formatter');
const a = format('SELECT 1 . /*x*/ 5e', { language: 'mysql' });
const b = format(a, { language: 'mysql' });
// a === "SELECT\n  1./*x*/ 5e"
// b === "SELECT\n  1. /*x*/ 5e"   <- a space appears after "1."
console.log(a === b); // false

First pass glues the . onto the 1; second pass reads 1. as a number literal and re-spaces it. That double-format divergence is the real symptom.

I overstated the description: the plain 1 . x and 1 . a cases are actually idempotent (they settle to 1.x / 1.a), so "swallows the property-access operator" was wrong. The honest scope is just that a . glued onto a bare integer literal isn't a stable layout.

If you don't think that edge earns a guard, feel free to close — no argument here. If you do, I'll rewrite the description and the test around the double-format case above instead of the misleading framing.

Thanks for the quick explanation. In that case I'll close this PR.

There are enough problems with the formatter not handling valid SQL. No need to complicate things further with trying to handle invalid SQL.