Skip to content

Commit ec8e076

Browse files
ShridharGoelShridharGoel
committed
Merge branch 'main' of https://github.com/Expensify/App into travelEnablement
2 parents f9f1c76 + d90c0fc commit ec8e076

381 files changed

Lines changed: 11439 additions & 4364 deletions

File tree

Some content is hidden

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

‎.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
----

‎__mocks__/react-native.ts‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -45,7 +45,7 @@ jest.doMock('react-native', () => {
4545
NativeModules: {
4646
...ReactNative.NativeModules,
4747
BootSplash: {
48-
hide: jest.fn(),
48+
hide: jest.fn().mockResolvedValue(undefined),
4949
logoSizeRatio: 1,
5050
navigationBarHeight: 0,
5151
},

‎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 1009022801
118-
versionName "9.2.28-1"
117+
versionCode 1009023000
118+
versionName "9.2.30-0"
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"

‎android/gradle.properties‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -62,4 +62,4 @@ org.gradle.parallel=true
6262
patchedArtifacts.packageName=react-standalone
6363

6464
# Change this property to false if you want to use prebuilt react-native artifacts.
65-
patchedArtifacts.forceBuildFromSource=true
65+
patchedArtifacts.forceBuildFromSource=false

‎codecov.yml‎

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -18,9 +18,9 @@ codecov:
1818

1919
comment:
2020
require_changes: "coverage_drop OR uncovered_patch"
21-
layout: "condensed_header, diff, files, condensed_footer"
22-
behavior: default
21+
layout: "condensed_header, files"
2322
hide_project_coverage: true
23+
hide_comment_details: false
2424

2525
flags:
2626
unit:

‎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

0 commit comments

Comments
 (0)