FE7: The modern frontend toolkit
Environments, configuration and error monitoring
🎯You'll be able to
Keep secrets out of the browser and set up error monitoring.
🏠The everyday picture
A theatre rehearses on a practice stage before opening night, and keeps an usher watching the audience during the show. Separate environments are the practice stage; error monitoring is the usher.
📘What it really is
-
Environments: typically development (your machine), staging or preview (a copy for testing), and production (real users). Each points to its own API, payment mode and analytics.
-
Environment variables configure each one. In Vite, only variables starting with
VITE_reach browser code; in Next.js,NEXT_PUBLIC_(FE3). Anything in browser code is visible to users, so no secrets in frontend variables. -
Keep
.envfiles with real values out of Git; commit an.env.examplelisting the names. -
Source maps connect minified production code back to your source, so error reports are readable. Upload them to your monitoring tool rather than serving them publicly if you don't want your source visible.
-
Error monitoring (such as Sentry) collects JavaScript errors from real users with the browser, page and steps that led there. Set it to avoid sending personal data, and alert on new or rising errors.
-
Version each release so errors can be traced to the release that caused them.
📝A worked example
Kirana Express configuration:
| Variable | Development | Preview | Production |
|---|---|---|---|
VITE_API_URL |
localhost:4000 | api-staging.kirana.example | api.kirana.example |
VITE_PAYMENT_MODE |
test | test | live |
VITE_SENTRY_ENV |
(off) | preview | production |
A week after release 3.4, error monitoring showed a new error, "Cannot read properties of undefined (reading 'slots')", from 2% of checkout visits, all on stores with no delivery slots that day. The source map pointed to the exact line, and a fix shipped the same afternoon.
🌍Where it's used
- Every production app.
- Teams with preview deployments for each pull request (FE9).
- Support: error reports explain "it didn't work" complaints.
📝Case scenario
A developer commits a .env file containing a third-party API key, and the repository is public. Even after deleting the file, the key
is in Git history. You rotate the key with the provider, add .env to .gitignore, commit .env.example instead, and turn on secret
scanning for the repository.
🖱️Try it
Set up development and preview configurations for your Kirana app with an .env.example. Add an error monitoring tool (a free tier is
enough), trigger a deliberate error, and check that the report shows the source file and line.
⚠️Common mistakes
- Putting a secret in a public environment variable. Sign: the key shows in the browser's source. Fix: only values safe for anyone to see go in public variables; secrets stay on the server.
- Sending personal data to the error monitor. Sign: customer phone numbers in error reports. Fix: strip personal fields before sending.
🛠️For your project
The kit's .env.example holds only practice values. The project pages refuse text that looks like a real secret.
✅Quick check
Which Vite environment variables reach browser code?
Show the answer
Those starting with VITE_, which means they must never hold secrets.
What do source maps do?
Show the answer
They map minified production code back to the original source, so errors can be traced to the right line.