[Due for payment 2025-12-01] Fix Rock.js Cache Misses by Permanently Ignoring bundle.js in Fingerprints

[mountiny]

Coming from here

Background

Rock.js uses a “fingerprint” system - a hash of project files - to identify and retrieve builds from our remote cache on GitHub Artifacts. This system is designed to skip local builds if no relevant source code has changed, retrieving the pre-built artifact from the cache instead.

A key file involved in the mobile build is Mobile-Expensify/Android/assets/app/shared/bundle.js. This file is not source code; it is a build artifact generated by a Grunt task during the build process. As such, it is correctly listed in .gitignore and is not checked into source control.

This setup creates an asymmetry in how fingerprints are calculated between our Continuous Integration (CI) environment and a developer’s local machine - read more about it in the comments section.

Problem

When a developer has a locally-generated bundle.js artifact from a previous build and no source code has changed, if they run the build command, then Rock includes the bundle.js artifact in the fingerprint, which causes a mismatch with the CI-generated cache and forces a time-consuming, unnecessary local rebuild. Bundle.js simply affects fingerprint and the local fingerprint is always different that cached ones available in Github Actions Artifacts.

Solution

We will permanently add bundle.js to the fingerprint.ignorePaths in the main rock.config.mjs file. This is the correct semantic solution, as build artifacts should never be part of a source-based fingerprint.

I propose we merge the following configuration into the main rock.config.mjs file:

// rock.config.mjs
export default {
    // ... other config
    fingerprint: {
		        ignorePaths: ['Mobile-Expensify/Android/assets/app/shared/bundle.js'],
    },
};

This ensures that the fingerprints match, and the cache works as intended. This change is safe: because all source files (like app/shared/index.js) are still part of the fingerprint, any change to them will correctly invalidate the cache and trigger a new build as intended

Issue Owner

Current Issue Owner: @strepanier03

[melvin-bot]

Triggered auto assignment to @strepanier03 (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[szymonzalarski98]

Started working on this

[melvin-bot]

@szymonzalarski98 6 days overdue. This is scarier than being forced to listen to Vogon poetry!