Skip to content

Commit 83d70e5

Browse files
samranahmsamranahm
authored
Merge branch 'Expensify:main' into 71598/check-isUploaded
2 parents 31ff5c8 + 35e6f75 commit 83d70e5

File tree

68 files changed

+1018
-625
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

68 files changed

+1018
-625
lines changed

‎.claude/agents/code-inline-reviewer.md‎

Lines changed: 12 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -228,21 +228,23 @@ const {amountColumnSize, dateColumnSize, taxAmountColumnSize} = useMemo(() => {
228228
- `body`: Concise and actionable description of the violation and fix, following the below Comment Format
229229
4. **Each comment must reference exactly one Rule ID.**
230230
5. **Output must consist exclusively of calls to mcp__github_inline_comment__create_inline_comment in the required format.** No other text, Markdown, or prose is allowed.
231-
6. **If no violations are found, output exactly** (with no quotes, markdown, or additional text):
231+
6. **If no violations are found, create a comment** (with no quotes, markdown, or additional text):
232232
LGTM :feelsgood:. Thank you for your hard work!
233233
7. **Output LGTM if and only if**:
234234
- You examined EVERY line of EVERY changed file
235235
- You checked EVERY changed file against ALL rules
236236
- You found ZERO violations matching the exact rule criteria
237237
- You verified no false negatives by checking each rule systematically
238-
If you found even ONE violation or have ANY uncertainty do NOT output LGTM - create inline comments instead.
238+
If you found even ONE violation or have ANY uncertainty do NOT create LGTM comment - create inline comments instead.
239239
8. **DO NOT invent new rules, stylistic preferences, or commentary outside the listed rules.**
240-
9. **DO NOT describe what you are doing, output any summaries, explanations, extra content, comments on rules that are NOT violated or ANYTHING ELSE except from rules violations or LGTM message.**
240+
9. **DO NOT describe what you are doing, create comments with a summary, explanations, extra content, comments on rules that are NOT violated or ANYTHING ELSE.**
241+
Only inline comments regarding rules violations or general comment with LGTM message are allowed.
241242
EXCEPTION: If you believe something MIGHT be a Rule violation but are uncertain, err on the side of creating an inline comment with your concern rather than skipping it.
242243

243244
## Tool Usage Example
244245

245-
For each violation, call the tool like this:
246+
For each violation, call the mcp__github_inline_comment__create_inline_comment tool like this.
247+
CRITICAL: **DO NOT** use the Bash tool for inline comments:
246248

247249
```
248250
mcp__github_inline_comment__create_inline_comment:
@@ -251,6 +253,12 @@ mcp__github_inline_comment__create_inline_comment:
251253
body: "<Body of the comment according to the Comment Format>"
252254
```
253255

256+
If ZERO violations are found, use the Bash tool to create a top-level PR comment.:
257+
258+
```bash
259+
gh pr comment --body "LGTM :feelsgood:. Thank you for your hard work!"
260+
```
261+
254262
## Comment Format
255263

256264
```

‎Mobile-Expensify‎

‎README.md‎

Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -100,4 +100,8 @@ to help run our Unit tests.
100100
## Performance tests
101101
We use Reassure for monitoring performance regression. More detailed information can be found [here](tests/perf-test/README.md):
102102

103+
## CodeCov
104+
105+
[CodeCov] is the service we use to measure and track code coverage. You can find out more about it [here](contributingGuides/CodeCov.md)
106+
103107
----

‎android/app/build.gradle‎

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -114,8 +114,8 @@ android {
114114
minSdkVersion rootProject.ext.minSdkVersion
115115
targetSdkVersion rootProject.ext.targetSdkVersion
116116
multiDexEnabled rootProject.ext.multiDexEnabled
117-
versionCode 1009022900
118-
versionName "9.2.29-0"
117+
versionCode 1009022901
118+
versionName "9.2.29-1"
119119
// Supported language variants must be declared here to avoid from being removed during the compilation.
120120
// This also helps us to not include unnecessary language variants in the APK.
121121
resConfigs "en", "es"

‎contributingGuides/CodeCov.md‎

Lines changed: 22 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,22 @@
1+
## CodeCov
2+
3+
[CodeCov](https://about.codecov.io/) is the service we use to measure and track [code coverage](https://about.codecov.io/resource/what-is-code-coverage/). It comments on PRs with metrics that authors and reviewers can use to judge the relative safety of the code. It's one metric and shouldn't be used in isolation, but it can provide valuable insight into how risky a PR might be.
4+
5+
The comment will provide you with a table of information similar to the one below:
6+
| [Files with missing lines](https://app.codecov.io/gh/blimpich/App/pull/3?dropdown=coverage&src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=Ben+Limpich) | Coverage Δ | |
7+
|---|---|---|
8+
| [src/libs/file_a.ts](https://app.codecov.io/gh/Expensify/App) | `50.58% <0.00%> (-1.20%)` | :arrow_down: |
9+
| [src/libs/file_b.ts](https://app.codecov.io/gh/Expensify/App) | `67.79% <ø> (ø)` | |
10+
| [src/libs/file_c.ts](https://app.codecov.io/gh/Expensify/App) | `73.64% <ø> (+2.32%)` | :arrow_up: |
11+
| [src/libs/file_d.ts](https://app.codecov.io/gh/Expensify/App) | `98.11% <100.00%> (+0.15%)` | :arrow_up: |
12+
13+
The first number in the `Coverage Δ` column is the coverage that the file currently has on `main`. The second number is the "patch-level coverage," so it represents the code coverage for PR changes itself. The third and final number is the overall change in code coverage % for that file. Lets run through these examples to get a better idea how this plays out:
14+
15+
- `file_a` seems to have no tests for it's changes, so patch coverage is 0% and we decrease overall coverage of the file by 1.2%
16+
- `file_b` appears to have been altered, but not in a way that changed coverage, so the PR probably updated a comment or something that isn't part of our coverage calculation (ex: translation file changes)
17+
- `file_c` has no change in patch coverage but an increase in overall coverage. This happens if we just add tests but don't add new code that needs to be tested
18+
- `file_d` has 100% patch coverage so we added tests for all our changes there, but the file still has some untested lines, so we only increased the overall coverage by 0.15%
19+
20+
If a file has existing coverage, we should _always_ be trying to increase or maintain the existing level of coverage. That way, over time, our code coverage will increase, we will catch more bugs in the PR-stage, and fewer PRs will have to be reverted. Decreasing coverage for a file should be avoided! So the above example would need more tests to cover `file_a`'s changes in order to be merged. To get more granular information on what exact lines are and aren't covered in your PR and in the file as a whole you can click on the hyperlinked files or go to `https://app.codecov.io/gh/Expensify/App/pull/<your_PR_number>` to look at the full coverage report.
21+
22+
If you find an issue with the generated coverage report please reach out to an Expensify engineer in our [open-source Slack channel](https://expensify.enterprise.slack.com/archives/C01GTK53T8Q).

‎contributingGuides/SETUP_WEB.md‎

Lines changed: 14 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -29,7 +29,20 @@ If you're using another operating system, you will need to ensure `mkcert` is in
2929
- Changes applied to Javascript will be applied automatically via WebPack as configured in `webpack.dev.ts`
3030

3131
### Production Build
32-
- To run the production web build: `npm run web:prod`
32+
To build and run the production web build locally:
33+
34+
```bash
35+
# 1. Set USE_WEB_PROXY environment variable in .env.production
36+
USE_WEB_PROXY=true
37+
38+
# 2. Build the production bundle
39+
npm run build
40+
41+
# 3. Run the distribution server
42+
npm run web:dist
43+
```
44+
45+
The `web:dist` command starts both the proxy server (port 9000) and web server (port 8080) concurrently. Access the application at **http://localhost:8080**
3346

3447
## Environment Variables
3548

‎contributingGuides/philosophies/BETAS.md‎

Lines changed: 91 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,91 @@
1+
# Beta Usage Philosophy
2+
This philosophy guides our approach to beta releases by emphasizing small incremental releases over betas.
3+
4+
#### Related Philosophies
5+
- [Small Incremental Releases Philosophy](/contributingGuides/philosophies/INCREMENTAL-RELEASES.md)
6+
- [Over-engineering Philosophy](/contributingGuides/philosophies/OVERENGINEERING.md)
7+
8+
#### Terminology
9+
- **Beta** - A mechanism that controls access to new functionality for limited users
10+
- **Beta Feature** - Functionality deployed to production but hidden behind a beta control
11+
- **Beta Control** - A mechanism to enable/disable features for specific users or groups without deploying new code
12+
- **Beta Rollout** - The process of gradually enabling a beta feature for larger audiences
13+
14+
## Rules
15+
16+
### - Betas SHOULD be avoided in favor of small incremental releases
17+
Our primary strategy is shipping small, complete features directly to production rather than releasing large, incomplete features in beta. This approach provides faster feedback, reduces complexity, and delivers value immediately.
18+
19+
Use betas only when:
20+
- The feature cannot be meaningfully decomposed into smaller units
21+
- There are significant business or technical risks that require validation before full release
22+
- Gradual rollout is needed to monitor performance or system impact
23+
24+
### - Beta roll-out MUST have clear removal criteria
25+
Every beta MUST have:
26+
- Specific criteria for removing the beta and fully releasing the feature
27+
- A GH that clearly defines when and how a beta will be removed
28+
29+
### - Betas MUST NOT be used for an excuse to roll out low-quality code
30+
Bad Example: A feature is built with a lot of bugs, but it's OK because it's behind a beta and therefore won't impact users or QA.
31+
32+
## When Beta Controls Are Appropriate
33+
34+
### - Beta MUST be used if a feature requires gradual rollout
35+
When you need to monitor system performance, user adoption, or business metrics as you enable features for larger audiences.
36+
When changes could significantly affect core user workflows and you need to validate the impact with real users before full release.
37+
38+
## Examples
39+
40+
### ❌ Inappropriate Beta Usage
41+
**Scenario**: New expense submission form
42+
**Beta approach**: Put form behind beta control for 6 weeks to "get feedback"
43+
**Problems**:
44+
- Form could be released incrementally (one field improvement at a time)
45+
- Low technical risk doesn't justify beta control
46+
- Extended timeline delays value delivery
47+
- Creates complexity for minimal benefit
48+
49+
### ✅ Appropriate Beta Usage
50+
**Scenario**: New AI-powered expense categorization system
51+
**Beta approach**: Beta control with gradual rollout over 3 weeks
52+
**Justification**:
53+
- Cannot be meaningfully decomposed (AI model needs holistic evaluation)
54+
- High technical risk (AI predictions could impact user trust)
55+
- Need to monitor system performance with AI processing load
56+
- Requires real usage data to validate accuracy
57+
58+
**Rollout plan**:
59+
- 5% of users, monitor accuracy and performance
60+
- 25% of users if metrics meet thresholds
61+
- 100% rollout if success criteria met
62+
63+
**Success criteria**:
64+
- 85% categorization accuracy
65+
- No performance degradation (response times under 200ms)
66+
- Error rate under 1%
67+
- Positive user feedback on suggestions
68+
69+
## Beta Removal Strategy
70+
71+
### - Define removal criteria upfront
72+
Before adding a new beta beta, establish quantifiable criteria for full rollout or feature termination.
73+
74+
Create GHs to track what needs to happen for a given beta.
75+
76+
### - Plan for three outcomes
77+
1. **Removal**: Remove beta control and enable for all users
78+
2. **Iteration**: Modify feature based on beta data, continue gradual rollout
79+
3. **Rollback**: Disable beta control and return to drawing board
80+
81+
### - Monitor graduation metrics continuously
82+
Track key performance indicators throughout the beta period:
83+
- System performance impact
84+
- Error rates and user feedback
85+
- Business metrics (conversions, retention, etc.)
86+
87+
### - Clean up removed betas
88+
Once features graduate to full release:
89+
- Remove beta control code and configuration
90+
- Update documentation to reflect new baseline functionality
91+
- Document lessons learned for future beta processes

‎contributingGuides/philosophies/INCREMENTAL-RELEASES.md‎

Lines changed: 72 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,72 @@
1+
# Small Incremental Releases Philosophy
2+
This philosophy guides our approach to breaking down large projects into smaller, independently releases that deliver value early and often.
3+
4+
#### Related Philosophies
5+
- [Over-engineering Philosophy](/contributingGuides/philosophies/OVERENGINEERING.md)
6+
- [Optimization Philosophy](/contributingGuides/philosophies/OPTIMIZATION.md)
7+
8+
#### Terminology
9+
- **Incremental Release** - A small, independently unit of work that delivers tangible value
10+
- **Release Stage** - A logical grouping of work that can stand alone if needed
11+
- **Dependencies** - Work that must be completed before other work can begin
12+
- **ROI** - Return on Investment, the value delivered versus the cost to implement
13+
14+
## Rules
15+
16+
### - Large projects MUST be broken into small incremental releases
17+
Big projects are rarely "one and done". They involve a series of releases, each building a foundation for the next. Break projects into the smallest pieces that can be incrementally deployed for customers to get value and provide early feedback. It MUST be possible to pause indefinitely after each release without serious trouble.
18+
19+
### - Releases MUST have a descriptive name
20+
Each release MUST have a descriptive name of the feature that will be released, instead of a generic v2 appended to the name.
21+
22+
#### Examples
23+
✅ GOOD: Release 1: Add ungrouped Accounting > Unapproved cash
24+
❌ BAD: Suggested Search: Accounting Workflows v1
25+
26+
27+
### - Releases MUST include adding help documentation and training the team
28+
Each release MUST come with a set of help documentation and training the team on the new feature.
29+
### - Releases SHOULD be minimally scoped
30+
Each release SHOULD achieve the least it possibly can while still accomplishing something meaningful. Resist merging releases together - it's faster to do two small, obvious releases than one large, less-obvious release. They are easier to write, easier to test, easier to review, and easier to revert.
31+
32+
## Examples
33+
34+
### ❌ Monolithic Release Approach
35+
**Project**: New expense reporting system
36+
**Monolithic approach**: Build complete system with:
37+
- User authentication
38+
- Expense submission
39+
- Approval workflows
40+
- Reporting dashboard
41+
- Mobile app
42+
- Integrations with 5 external systems
43+
44+
**Problems**:
45+
- 6-month development cycle with no user feedback
46+
- High risk if any component fails
47+
- No value delivered until everything is complete
48+
49+
### ✅ Incremental Release Approach
50+
**Project**: New expense reporting system
51+
52+
**Release 1**: Basic expense submission (web only)
53+
- Users can submit expenses manually
54+
- Admin can approve/reject in simple interface
55+
- **Value**: Immediate replacement of paper/email process
56+
57+
**Release 2**: Receipt capture
58+
- Users can photograph receipts
59+
- Basic OCR for expense details
60+
- **Value**: Reduces manual data entry
61+
62+
**Release 3**: Approval workflows
63+
- Multi-level approval routing
64+
- Email notifications
65+
- **Value**: Automates approval process for larger organizations
66+
67+
**Release 4**: Reporting dashboard
68+
- Basic expense reports and analytics
69+
- Export capabilities
70+
- **Value**: Provides visibility into spending patterns
71+
72+
Each release delivers immediate value while building toward the complete vision.

‎contributingGuides/philosophies/INDEX.md‎

Lines changed: 5 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -5,15 +5,19 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S
55
"OPTIONAL" are to be interpreted as described in [RFC 2119](https://datatracker.ietf.org/doc/html/rfc2119).
66

77
## Contents
8+
* [Beta Usage Philosophy](/contributingGuides/philosophies/BETAS.md)
89
* [Cross-Platform Philosophy](/contributingGuides/philosophies/CROSS-PLATFORM.md)
910
* [Data Flow Philosophy](/contributingGuides/philosophies/DATA-FLOW.md)
1011
* [Async vs. Sync Code](/contributingGuides/philosophies/ASYNC.md)
1112
* [Data Binding Philosophy](/contributingGuides/philosophies/DATA-BINDING.md)
1213
* [Deploying Philosophy](/contributingGuides/philosophies/DEPLOYING.md)
1314
* [Directory Structure and File Naming Philosophy](/contributingGuides/philosophies/DIRECTORIES.md)
14-
* [Internationalization Philosophy](/contributingGuides/philosophies/INTERNATIONALIZATION.md)
1515
* [HybridApp Philosophy](/contributingGuides/philosophies/HYBRID-APP.md)
16+
* [Small Incremental Releases Philosophy](/contributingGuides/philosophies/INCREMENTAL-RELEASES.md)
17+
* [Internationalization Philosophy](/contributingGuides/philosophies/INTERNATIONALIZATION.md)
1618
* [Offline Philosophy](/contributingGuides/philosophies/OFFLINE.md)
1719
* [Onyx Data Management Philosophy](/contributingGuides/philosophies/ONYX-DATA-MANAGEMENT.md)
20+
* [Over-engineering Philosophy](/contributingGuides/philosophies/OVERENGINEERING.md)
21+
* [Optimization Philosophy](/contributingGuides/philosophies/OPTMIZATION.md)
1822
* [Routing Philosophy](/contributingGuides/philosophies/ROUTING.md)
1923
* [Security Philosophy](/contributingGuides/philosophies/SECURITY.md)

‎contributingGuides/philosophies/OPTIMIZATION.md‎

Lines changed: 45 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,45 @@
1+
# Optimization Philosophy
2+
This philosophy guides our approach to optimization by focusing on proven problems rather than hypothetical issues across all aspects of development and processes.
3+
4+
#### Related Philosophies
5+
- [Over-engineering Philosophy](/contributingGuides/philosophies/OVERENGINEERING.md)
6+
7+
#### Terminology
8+
- **Optimization** - making something faster, more flexible, or more capable than it needs to be to solve the exact problems agreed upon
9+
- **Pre-optimizing** - Optimizing a solution before identifying actual problems
10+
- **Bottleneck** - A confirmed point in the process that limits overall results
11+
- **Measuring** - Collecting actual data about process performance or outcomes
12+
13+
## Rules
14+
15+
### - Optimizations MUST be based on measured problems
16+
Do not optimize processes or solutions unless you have:
17+
- Identified a specific problem through user reports, metrics, or observation
18+
- Measured the issue with appropriate tools or data collection
19+
- Confirmed the optimization target is actually a bottleneck
20+
21+
Optimizations can be added later if and when they become necessary.
22+
23+
### - Optimizations MUST be measured before and after implementation
24+
When implementing process improvements:
25+
- Establish baseline measurements before optimization
26+
- Implement the optimization
27+
- Measure the actual improvement gained
28+
- Document the results achieved
29+
30+
31+
## When to Optimize
32+
### - Known issues
33+
When we have concrete data about existing usage patterns that indicate the current approach will fail. This is distinct from pre-optimizing because it's based on actual, measurable constraints rather than hypothetical "what if" scenarios.
34+
- Existing customer data volumes that would break the system
35+
- Known need to expand the feature in the foreseeable future
36+
37+
### - User-reported issues
38+
When users report that processes are slow, confusing, or inefficient in specific scenarios.
39+
40+
### - Metrics indicate problems
41+
When monitoring shows:
42+
- Increased completion times
43+
- Higher error rates
44+
- Resource bottlenecks
45+
- User satisfaction declining

0 commit comments

Comments
 (0)