fix(policy): reject bundle ids with a trailing/edge hyphen by cblue0372-coder · Pull Request #545 · profullstack/sh1pt

cblue0372-coder · 2026-06-01T11:09:04Z

Problem

The bundle-id rule's BUNDLE_RE used [a-zA-Z][a-zA-Z0-9-]* per label, which let a label end with a hyphen — so com.foo.bar- passed validation. Apple App Store Connect and Google Play both reject a bundle/application id whose label ends with (or doubles) a hyphen, so the linter gave a false pass the stores would later bounce.

Fix

Tighten the pattern so hyphens are only allowed between alphanumerics within a label: [a-zA-Z][a-zA-Z0-9]*(-[a-zA-Z0-9]+)*. All previously valid ids still pass; only genuinely store-invalid hyphen placements now fail. Adds a vitest spec (valid ids, internal hyphens, trailing/leading-hyphen and single-segment rejections).

Tests

pnpm exec vitest run packages/policy/src/rules/bundle-id.test.ts → 5 passed.

The bundle-id rule's BUNDLE_RE used `[a-zA-Z][a-zA-Z0-9-]*` per label, which let a label end with a hyphen — so "com.foo.bar-" passed validation. Apple App Store Connect and Google Play both reject a bundle/application id whose label ends with (or doubles) a hyphen, so the linter was giving a false pass that the stores would later bounce. Tighten the pattern so hyphens are only allowed between alphanumerics within a label (`[a-zA-Z][a-zA-Z0-9]*(-[a-zA-Z0-9]+)*`). All previously valid ids still pass; only genuinely store-invalid hyphen placements now fail. Add a vitest spec covering valid ids, internal hyphens, and the trailing/leading-hyphen and single-segment rejections.

greptile-apps · 2026-06-01T11:11:09Z

Greptile Summary

Tightens the BUNDLE_RE regex in the bundle-id policy rule so that a reverse-DNS label can no longer end with a hyphen, fixing a false-pass that Apple App Store Connect and Google Play would later reject. A new vitest spec is added covering valid ids, internal hyphens, and the newly-rejected placements.

bundle-id.ts: replaces [a-zA-Z][a-zA-Z0-9-]* per label with [a-zA-Z][a-zA-Z0-9]*(-[a-zA-Z0-9]+)*, ensuring hyphens appear only between alphanumeric characters and never at a label boundary.
bundle-id.test.ts: adds five test cases (two valid, three invalid) to lock in the new behaviour; the "doubled hyphen" case mentioned in the PR description is absent from the spec though the regex rejects it correctly.

Confidence Score: 4/5

Safe to merge — the regex change is correct and all existing valid bundle IDs continue to pass.

The regex fix is logically sound and the five new tests confirm the intended behaviour. The only gap is that the doubled-hyphen case called out in the PR description has no corresponding spec, so a future regression there would be silent.

bundle-id.test.ts — worth adding a doubled-hyphen test case to match the PR description's stated rejection rules.

Important Files Changed

Filename	Overview
packages/policy/src/rules/bundle-id.ts	Regex tightened to prevent trailing/leading hyphens per label; new pattern is logically correct for all described edge cases.
packages/policy/src/rules/bundle-id.test.ts	New vitest spec covers valid ids, internal hyphens, trailing hyphen, leading hyphen, and single segment — missing a test for the doubled-hyphen case mentioned in the PR description.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[bundleId string] --> B{BUNDLE_RE.test}
    B -- "passes" --> C{com.example.* ?}
    C -- "yes" --> E[Finding: reserved namespace]
    C -- "no" --> F[No findings ✓]
    B -- "fails" --> D[Finding: not valid reverse-DNS]

    subgraph BUNDLE_RE ["BUNDLE_RE pattern breakdown"]
        direction LR
        P1["^ [a-zA-Z]"] --> P2["[a-zA-Z0-9]*"] --> P3["(-[a-zA-Z0-9]+)*"] --> P4["(\\. label)+ $"]
    end

_{Reviews (1): Last reviewed commit: "fix(policy): reject bundle ids with a tr..." | Re-trigger Greptile}

greptile-apps · 2026-06-01T11:11:13Z

+  it('rejects a single-segment id (not reverse-DNS)', () => {
+    const findings = lint('com');
+    expect(findings.some((f) => /not valid reverse-DNS/.test(f.message))).toBe(true);
+  });
+});


The PR description explicitly calls out "doubled hyphen" (com.foo--bar) as a case that stores reject, but there is no test covering it. The new regex does reject it correctly ((-[a-zA-Z0-9]+)* cannot consume --bar because the second character after the first - is another -), but a regression in the pattern would go unnoticed without a spec for this case.

Suggested change

it('rejects a single-segment id (not reverse-DNS)', () => {

const findings = lint('com');

expect(findings.some((f) => /not valid reverse-DNS/.test(f.message))).toBe(true);

});

});

it('rejects a single-segment id (not reverse-DNS)', () => {

const findings = lint('com');

expect(findings.some((f) => /not valid reverse-DNS/.test(f.message))).toBe(true);

});

it('rejects a doubled hyphen within a label (com.foo--bar)', () => {

const findings = lint('com.foo--bar');

expect(findings.some((f) => /not valid reverse-DNS/.test(f.message))).toBe(true);

});

});

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

github-actions · 2026-06-01T14:09:47Z