Skip to content

Conversation

@psteinroe
Copy link
Collaborator

@psteinroe psteinroe commented Nov 4, 2025

rewires the pgls_configuration crate alongside its codegen xtask as a preparation for new lint tools (splinter and pglinter). its all the same as before, I just moved things in the config crate around, and the xtask is geared towards tools vs just the analyser. common primitives are now in /rules/, and we generate one dir per tool (linter, splinter, pglinter) etc.

the codegen refactoring was initially written by me but completed by Claude. Everything outside of xtask/ was done by hand or is re-generated.

TODO (in follow-up prs)

  • Rename pgls_analyser crate to pgls_linter
  • Create pgls_pglinter, pgls_splinter and pgls_assists and integrate them with pgls_analyse to allow a RuleVisitor to collect the metadata
  • Simplify common patterns between linter/splinter/pglinter - I think we can cleanup Analyser a bit.

use crate::{Rules, linter::RuleGroup};

#[derive(Clone, Copy, Debug, Eq, PartialEq, Hash)]
pub enum RuleSelector {
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this will be made more generic in a future pr

psteinroe and others added 5 commits November 4, 2025 10:30
- Fix unresolved import from analyser to linter in workspace tests
- Remove empty line after outer attribute in diagnostics
- Apply clippy suggestions for cleaner code

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <[email protected]>
- Add ORDER BY clause to roles query for deterministic results
- Update role completion tests to expect all default Supabase roles
- Create helper function to centralize expected roles list
- Update SQLx offline cache for modified query

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <[email protected]>
Copy link
Collaborator

@juleswritescode juleswritescode left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good!

The way I understand it is: "rules" are an abstraction layer over lints, actions, transformations.

Then the "lints" will come from many tools: splinter, pglinter, and so on.

What's still throwing me off a bit is that our lint rules (mostly squawk, eugene, typecheck?) are called "linter" right now. Maybe we can somehow make it more clear that linter is one of many linters by naming it "internal" or something?

@psteinroe
Copy link
Collaborator Author

Looks good!

The way I understand it is: "rules" are an abstraction layer over lints, actions, transformations.

Then the "lints" will come from many tools: splinter, pglinter, and so on.

What's still throwing me off a bit is that our lint rules (mostly squawk, eugene, typecheck?) are called "linter" right now. Maybe we can somehow make it more clear that linter is one of many linters by naming it "internal" or something?

The idea is that "rules" are the abstraction for not only lints, actions and transformations, but also for diagnostics emitted from other tools such as splinter.

and the linter is the "source code rules engine", and it emits "normal" lints. we will then add another crate for assists and transformations if we need them.

The other tools (eg splinter) are also declaring "rules" and emit diagnostics for rules, but are not declared as "linter".

But I agree that it's not 100% perfect. Open to suggestions, but I have troubles finding a name for the "source code linter" that is not "linter".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants