| Dimension | Shared | Only in A | Only in B | Overlap |
|---|---|---|---|---|
| Sections | 0 | 1 | 12 | 0% |
| Commands | 0 | 0 | 0 | — |
| Section tags | 1 | 0 | 7 | 13% |
What each file covers
Sections
0 shared · 1 only in A · 12 only in B- − TDD
- + Code Style and Structure
- + Naming Conventions
- + Ruby and Rails Usage
- + Syntax and Formatting
- + Error Handling and Validation
- + UI and Styling
- + Internationalization (i18n)
- + Controller Patterns
- + Performance Optimization
- + Key Conventions
- + Testing
- + Security
Commands
neither file has anySection tags
1 shared · 0 only in A · 7 only in B- + test
- + lint-format
- + code-style
- + architecture
- + security
- + ui
- + performance
- testing-strategy
Line diff
aviemet/inventory · .cursor/rules/conventions.mdc
@@ −1 @@
1---
2description:
3globs:
4alwaysApply: true
5---
6
7Only work on the task at hand. Limit the scope of your response to exactly what is being worked on in the moment.
8
9### TDD
10
11For every change, find the corresponding test and ensure it passes.
12Ensure that the tests accurately test the interfaces, adjusting tests as needed to accurately test the intention of the code. Do not change tests to fit the implementation just to make them pass. The tests need to accurately indicate the intention of the code, and the code needs to be made to pass the tests, not the other way around.
13
14* For ruby files, tests are in /rspec
15* For typescript files, tests are in /app/frontend/tests
aviemet/inventory · .cursor/rules/rails.mdc
@@ +1 @@
1---
2description: Ruby on Rails
3globs: *.rb
4alwaysApply: false
5---
6You are an expert in Ruby on Rails and PostgreSQL
7
8## Code Style and Structure
9
10- Write concise, idiomatic Ruby code with accurate examples.
11- Follow Rails conventions and best practices.
12- Use object-oriented and functional programming patterns as appropriate.
13- Prefer iteration and modularization over code duplication.
14- Use descriptive variable and method names (e.g., user_signed_in?, calculate_total).
15- Structure files according to Rails conventions (MVC, concerns, helpers, etc.).
16
17## Naming Conventions
18
19- Use snake_case for file names, method names, and variables.
20- Use CamelCase for class and module names.
21- Follow Rails naming conventions for models, controllers, and views.
22
23## Ruby and Rails Usage
24
25- Use Ruby 3.x features when appropriate (e.g., pattern matching, endless methods).
26- Leverage Rails' built-in helpers and methods.
27- Use ActiveRecord effectively for database operations.
28- Follow the official Ruby on Rails guides for best practices in routing, controllers, models, views, and other Rails components.
29
30## Syntax and Formatting
31
32- Follow the Ruby Style Guide (https://rubystyle.guide/)
33- Use Ruby's expressive syntax (e.g., unless, ||=, &.)
34- Prefer single quotes for strings unless interpolation is needed.
35
36## Error Handling and Validation
37
38- Use exceptions for exceptional cases, not for control flow.
39- Implement proper error logging and user-friendly messages.
40- Use ActiveModel validations in models.
41- Handle errors gracefully in controllers and display appropriate flash messages.
42
43## UI and Styling
44
45- Remember that data flows to the front end using Inertia.js
46- The Rails view layer is not used, front end is done using React, loaded by Inertia.js
47
48## Internationalization (i18n)
49
50- Properly define strings in locale yml files; use a nested directory structure for locale files to keep things organized.
51- Define strings for the frontend in yml files as well; use the i18n-js gem to generate json files for the front end.
52- Implement proper locale detection.
53- Use proper number and date formatting.
54- Use proper currency formatting.
55- Implement proper RTL support.
56
57### Controller Patterns
58
59- Using "decent exposure" gem for defining common queries in controllers
60- Custom `strong_params` method on ApplicationController for defining strong parameters
61- `sortable_fields` method on ApplicationController helps define sortable fields for React Table components
62
63## Performance Optimization
64
65- Use database indexing effectively.
66- Implement caching strategies (fragment caching, Russian Doll caching).
67- Use eager loading to avoid N+1 queries.
68- Optimize database queries using includes, joins, or select.
69
70## Key Conventions
71
72- Follow RESTful routing conventions.
73- Use concerns for shared behavior across models or controllers.
74- Implement service objects for complex business logic.
75- Use background jobs (e.g., Goodjob) for time-consuming tasks.
76
77## Testing
78
79- Write comprehensive tests using RSpec.
80- Follow TDD/BDD practices.
81- Use factories (FactoryBot) for test data generation.
82- Do not use `let` for locally available definitions. Only use `let` when passing the test subject to a test defined in another file, or if it's the simpler approach for that specific test.
83
84 ### Unit Testing
85
86 - Write thorough unit tests to validate individual functions and components.
87 - Follow patterns like Arrange-Act-Assert to ensure clarity and consistency in tests.
88 - Mock external dependencies and API calls to isolate unit tests.
89
90 ### Integration Testing
91
92 - Focus on user workflows to ensure app functionality.
93 - Set up and tear down test environments properly to maintain test independence.
94
95 ### Inertia Testing
96
97 - Inertia has its own set of rspec assertions, use them when appropriate to test inertia specific actions. Examples below:
98
99 ```ruby
100 RSpec.describe '/events', inertia: true do
101 describe '#index' do
102 let!(:event) { Event.create!(title: 'Foo', start_date: '2024-02-21', description: 'Foo bar') }
103
104 it "renders inertia component" do
105 get events_path
106
107 # check the component
108 expect(inertia).to render_component 'Event/Index'
109 # or
110 expect_inertia.to render_component 'Event/Index'
111 # same as above
112 expect(inertia.component).to eq 'Event/Index'
113
114 # props (including shared props)
115 expect(inertia).to have_exact_props({title: 'Foo', description: 'Foo bar'})
116 expect(inertia).to include_props({title: 'Foo'})
117
118 # access props
119 expect(inertia.props[:title]).to eq 'Foo'
120
121 # view data
122 expect(inertia).to have_exact_view_data({meta: 'Foo bar'})
123 expect(inertia).to include_view_data({meta: 'Foo bar'})
124
125 # access view data
126 expect(inertia.view_data[:meta]).to eq 'Foo bar'
127 end
128 end
129 end
130 ```
131
132## Security
133
134- Implement proper authentication and authorization (e.g., Devise, Rolify, Pundit).
135- Use strong parameters in controllers, using the strong_params method defined in the strong_params.rb concern.
136- Protect against common web vulnerabilities (XSS, CSRF, SQL injection).
137
@@ −1 +1 @@
11 ---
2−description:
3−globs:
4−alwaysApply: true
2+description: Ruby on Rails
3+globs: *.rb
4+alwaysApply: false
55 ---
6+You are an expert in Ruby on Rails and PostgreSQL
7+
8+## Code Style and Structure
69
7−Only work on the task at hand. Limit the scope of your response to exactly what is being worked on in the moment.
10+- Write concise, idiomatic Ruby code with accurate examples.
11+- Follow Rails conventions and best practices.
12+- Use object-oriented and functional programming patterns as appropriate.
13+- Prefer iteration and modularization over code duplication.
14+- Use descriptive variable and method names (e.g., user_signed_in?, calculate_total).
15+- Structure files according to Rails conventions (MVC, concerns, helpers, etc.).
816
9−### TDD
17+## Naming Conventions
1018
11−For every change, find the corresponding test and ensure it passes.
12−Ensure that the tests accurately test the interfaces, adjusting tests as needed to accurately test the intention of the code. Do not change tests to fit the implementation just to make them pass. The tests need to accurately indicate the intention of the code, and the code needs to be made to pass the tests, not the other way around.
19+- Use snake_case for file names, method names, and variables.
20+- Use CamelCase for class and module names.
21+- Follow Rails naming conventions for models, controllers, and views.
1322
14−* For ruby files, tests are in /rspec
15−* For typescript files, tests are in /app/frontend/tests
23+## Ruby and Rails Usage
24+
25+- Use Ruby 3.x features when appropriate (e.g., pattern matching, endless methods).
26+- Leverage Rails' built-in helpers and methods.
27+- Use ActiveRecord effectively for database operations.
28+- Follow the official Ruby on Rails guides for best practices in routing, controllers, models, views, and other Rails components.
29+
30+## Syntax and Formatting
31+
32+- Follow the Ruby Style Guide (https://rubystyle.guide/)
33+- Use Ruby's expressive syntax (e.g., unless, ||=, &.)
34+- Prefer single quotes for strings unless interpolation is needed.
35+
36+## Error Handling and Validation
37+
38+- Use exceptions for exceptional cases, not for control flow.
39+- Implement proper error logging and user-friendly messages.
40+- Use ActiveModel validations in models.
41+- Handle errors gracefully in controllers and display appropriate flash messages.
42+
43+## UI and Styling
44+
45+- Remember that data flows to the front end using Inertia.js
46+- The Rails view layer is not used, front end is done using React, loaded by Inertia.js
47+
48+## Internationalization (i18n)
49+
50+- Properly define strings in locale yml files; use a nested directory structure for locale files to keep things organized.
51+- Define strings for the frontend in yml files as well; use the i18n-js gem to generate json files for the front end.
52+- Implement proper locale detection.
53+- Use proper number and date formatting.
54+- Use proper currency formatting.
55+- Implement proper RTL support.
56+
57+### Controller Patterns
58+
59+- Using "decent exposure" gem for defining common queries in controllers
60+- Custom `strong_params` method on ApplicationController for defining strong parameters
61+- `sortable_fields` method on ApplicationController helps define sortable fields for React Table components
62+
63+## Performance Optimization
64+
65+- Use database indexing effectively.
66+- Implement caching strategies (fragment caching, Russian Doll caching).
67+- Use eager loading to avoid N+1 queries.
68+- Optimize database queries using includes, joins, or select.
69+
70+## Key Conventions
71+
72+- Follow RESTful routing conventions.
73+- Use concerns for shared behavior across models or controllers.
74+- Implement service objects for complex business logic.
75+- Use background jobs (e.g., Goodjob) for time-consuming tasks.
76+
77+## Testing
78+
79+- Write comprehensive tests using RSpec.
80+- Follow TDD/BDD practices.
81+- Use factories (FactoryBot) for test data generation.
82+- Do not use `let` for locally available definitions. Only use `let` when passing the test subject to a test defined in another file, or if it's the simpler approach for that specific test.
83+
84+ ### Unit Testing
85+
86+ - Write thorough unit tests to validate individual functions and components.
87+ - Follow patterns like Arrange-Act-Assert to ensure clarity and consistency in tests.
88+ - Mock external dependencies and API calls to isolate unit tests.
89+
90+ ### Integration Testing
91+
92+ - Focus on user workflows to ensure app functionality.
93+ - Set up and tear down test environments properly to maintain test independence.
94+
95+ ### Inertia Testing
96+
97+ - Inertia has its own set of rspec assertions, use them when appropriate to test inertia specific actions. Examples below:
98+
99+ ```ruby
100+ RSpec.describe '/events', inertia: true do
101+ describe '#index' do
102+ let!(:event) { Event.create!(title: 'Foo', start_date: '2024-02-21', description: 'Foo bar') }
103+
104+ it "renders inertia component" do
105+ get events_path
106+
107+ # check the component
108+ expect(inertia).to render_component 'Event/Index'
109+ # or
110+ expect_inertia.to render_component 'Event/Index'
111+ # same as above
112+ expect(inertia.component).to eq 'Event/Index'
113+
114+ # props (including shared props)
115+ expect(inertia).to have_exact_props({title: 'Foo', description: 'Foo bar'})
116+ expect(inertia).to include_props({title: 'Foo'})
117+
118+ # access props
119+ expect(inertia.props[:title]).to eq 'Foo'
120+
121+ # view data
122+ expect(inertia).to have_exact_view_data({meta: 'Foo bar'})
123+ expect(inertia).to include_view_data({meta: 'Foo bar'})
124+
125+ # access view data
126+ expect(inertia.view_data[:meta]).to eq 'Foo bar'
127+ end
128+ end
129+ end
130+ ```
131+
132+## Security
133+
134+- Implement proper authentication and authorization (e.g., Devise, Rolify, Pundit).
135+- Use strong parameters in controllers, using the strong_params method defined in the strong_params.rb concern.
136+- Protect against common web vulnerabilities (XSS, CSRF, SQL injection).
137+
