Mise & runtime secrets setup by DarkoKukovec · Pull Request #105 · infinum/JS-React-Example

DarkoKukovec · 2026-04-16T11:26:24Z

No description provided.

github-actions · 2026-04-16T11:27:02Z

Coverage diff

Metric	PR	main	Δ
Statements	27.89%	N/A	N/A
Branches	44.07%	N/A	N/A
Functions	46.03%	N/A	N/A
Lines	26.58%	N/A	N/A

Base coverage artifact missing; only PR coverage is shown.

🧮 Per-package delta

Package	Metric	PR	main	Δ
`frontend`	Statements	20.09%	N/A	N/A
	Branches	35.41%	N/A	N/A
	Functions	21.62%	N/A	N/A
	Lines	20.09%	N/A	N/A
`ui`	Statements	80.00%	N/A	N/A
	Branches	81.81%	N/A	N/A
	Functions	80.76%	N/A	N/A
	Lines	82.47%	N/A	N/A

DarkoKukovec · 2026-05-12T14:18:19Z

+# bash is needed by the wrapper shims under ./scripts (with-mise.sh,
+# with-secrets.sh) that root + per-app pnpm scripts route through.
+# Alpine ships only busybox sh, which lacks the bashisms ([[ ]], arrays).
+RUN apk add --no-cache bash && corepack enable


Not sure if this is worth doing or there is a better way...

Shouldn't we completely get rid of corepack already and switch to mise in CI/CD also?

https://mise.jdx.dev/continuous-integration.html#github-actions

DarkoKukovec · 2026-05-12T14:25:09Z

+
+When multiple apps each declare their own secrets, the driver layers them so the host process has all secrets in env by the time `docker compose up` runs. **Compose's `environment:` block is what enforces isolation between services** — each service forwards only the names it lists. So even though the host process briefly holds both frontend's and backend's secrets, the frontend container only sees `NEXTAUTH_SECRET`, the backend container only sees `DATABASE_PASSWORD`, and storybook sees nothing.
+
+A subtle footgun worth knowing about: **don't share secret *names* between apps.** If `apps/frontend/.env.secret` and `apps/backend/.env.secret` both declare `API_KEY`, the layer that runs last wins for that name in the host process — and both services' `environment: - API_KEY` blocks will receive the same value. Use app-scoped names (`FRONTEND_API_KEY`, `BACKEND_API_KEY`) so each app's secret namespace stays disjoint.


I guess this might need more highlighting, maybe even runtime warnings?

DarkoKukovec · 2026-05-12T14:27:28Z

+
+## Daily usage
+
+Day-to-day, just use the pnpm scripts. The root scripts route through [scripts/with-mise.sh](../scripts/with-mise.sh) — a tiny shim that prefixes `mise exec --` when mise is on PATH, so the pinned toolchain is used even from a shell that hasn't been activated:


Not sure if this is overkill...

DarkoKukovec · 2026-05-12T14:30:34Z

- **`*.local` files** &mdash; Developer-specific overrides and secrets, never committed to git.
+- **`.env`** — Committed, non-secret host defaults for running the app on your local machine.
+- **`.env.compose`** — Committed, non-secret Docker defaults for running the app in containers.
+- **`.env.secret`** — Committed, but contains only **references** (e.g. `op://vault/item/field`), not resolved values. Read at task-run time by [scripts/with-secrets.sh](../scripts/with-secrets.sh).


Do we also need .env.secrets.local? Would be useful for switcing between envs?

DarkoKukovec · 2026-05-12T14:32:13Z

 - `.env.production.local`
 - `.env.test.local`
 - `.env.compose.local`
+- `.env.secret.local` (if anyone uses `op inject` to materialize resolved values locally)


Hmm, not sure if this works already... Maybe a better approach would be .env.secret.acpt, and then control with an env variable flag? e.g. pnpm dev -- acpt or something

DarkoKukovec · 2026-05-12T14:36:24Z

+
+### What if I don't have vault access yet?
+
+If you're onboarding and don't yet have access to the project's 1Password vault (or equivalent), ask in the team channel to be added. As a short-term workaround you can export the required secrets manually in your shell before running `pnpm dev` — the wrapper's `none` fallback will pass them through if no provider is configured, or you can force it with `SECRETS_PROVIDER=none pnpm dev`. This is a stopgap — the wrapper + vault flow is the supported path.


Not sure if we should mention the workaround...

kamdubiel

Only read the code without docs

kamdubiel · 2026-05-12T14:43:21Z

 !.env.compose
+# Provider-reference manifest for scripts/with-secrets.sh — pointers only,
+# never resolved values. See documentation/Environment variables.md.
+!.env.secret


I don't see reason to do another type of env file.

.env and .env.compose should be templates (no commented out lines like you did), so they should even contain the secrets env, but with "REPLACE_ME" or "SECRET" values. On localhost you very often don't even need to use those secrets for 3rd party SaaS, and if you do, you can point your scripts to .env.local and .env.compose.local that are generated automatically on postinstall, are not commited, and can serve as the containers for the secret variables if needed

kamdubiel · 2026-05-12T14:45:19Z

+# bash is needed by the wrapper shims under ./scripts (with-mise.sh,
+# with-secrets.sh) that root + per-app pnpm scripts route through.
+# Alpine ships only busybox sh, which lacks the bashisms ([[ ]], arrays).
+RUN apk add --no-cache bash && corepack enable


Shouldn't we completely get rid of corepack already and switch to mise in CI/CD also?

https://mise.jdx.dev/continuous-integration.html#github-actions

kamdubiel · 2026-05-12T14:51:36Z

@@ -1,8 +1,11 @@
-FROM node:24.11.0-alpine AS base
+FROM node:24.15.0-alpine AS base


If you're already having fun, make it 26.1.0 and get rid of corepack

kamdubiel · 2026-05-12T14:56:24Z

+
+[tools]
+node = "24.15.0"
+pnpm = "10.33.0"


Add this for the crazy vibecoders, just in case:

python = "3.14.3" jq = "1.8.1" yq = "4.52.4" rg = "15.1.0" fd = "10.4.2"

kamdubiel · 2026-05-12T14:56:45Z

 	"engines": {
-		"node": "24.11.0"
+		"node": "24.15.0",
+		"pnpm": "10.33.0"


Version 11 :)

kamdubiel · 2026-05-12T14:58:15Z

+
+allowBuilds:
+  sharp@0.34.5: true
+  core-js: false


No global allow please just in case core-js maintainer will have another meltdown over night

kamdubiel · 2026-05-12T15:01:22Z


- **`.env.local`**: Local development overrides
- **`.env.compose`**: Docker Compose environment
+- **`.env.local`**: Local development overrides (non-secret)


As I wrote - can have secrets but without values. Should serve as templates with all possible env variables

WIP mise setup

611d263

DarkoKukovec added 7 commits April 22, 2026 14:58

Better docs

8e11861

More docs updates

20aa2ed

Document mise story

98bec1c

Mise in main readme

8fad82a

Updated commands

6073825

Update node in docker

1863922

Add with-secret

97a9c73

DarkoKukovec changed the title ~~Mise setup~~ Runtime secrets setup May 12, 2026

DarkoKukovec changed the title ~~Runtime secrets setup~~ Mise & runtime secrets setup May 12, 2026

DarkoKukovec commented May 12, 2026

View reviewed changes

kamdubiel approved these changes May 12, 2026

View reviewed changes

Merge remote-tracking branch 'origin/main' into feature/setup-mise

bbefeec


		When multiple apps each declare their own secrets, the driver layers them so the host process has all secrets in env by the time `docker compose up` runs. Compose's `environment:` block is what enforces isolation between services — each service forwards only the names it lists. So even though the host process briefly holds both frontend's and backend's secrets, the frontend container only sees `NEXTAUTH_SECRET`, the backend container only sees `DATABASE_PASSWORD`, and storybook sees nothing.

		A subtle footgun worth knowing about: *don't share secret names* between apps.** If `apps/frontend/.env.secret` and `apps/backend/.env.secret` both declare `API_KEY`, the layer that runs last wins for that name in the host process — and both services' `environment: - API_KEY` blocks will receive the same value. Use app-scoped names (`FRONTEND_API_KEY`, `BACKEND_API_KEY`) so each app's secret namespace stays disjoint.


		## Daily usage

		Day-to-day, just use the pnpm scripts. The root scripts route through [scripts/with-mise.sh](../scripts/with-mise.sh) — a tiny shim that prefixes `mise exec --` when mise is on PATH, so the pinned toolchain is used even from a shell that hasn't been activated:


		### What if I don't have vault access yet?

		If you're onboarding and don't yet have access to the project's 1Password vault (or equivalent), ask in the team channel to be added. As a short-term workaround you can export the required secrets manually in your shell before running `pnpm dev` — the wrapper's `none` fallback will pass them through if no provider is configured, or you can force it with `SECRETS_PROVIDER=none pnpm dev`. This is a stopgap — the wrapper + vault flow is the supported path.

		@@ -1,8 +1,11 @@
		FROM node:24.11.0-alpine AS base
		FROM node:24.15.0-alpine AS base

Uh oh!

Conversation

DarkoKukovec commented Apr 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions Bot commented Apr 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Coverage diff

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

DarkoKukovec May 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

kamdubiel left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

DarkoKukovec commented Apr 16, 2026 •

edited

Loading

github-actions Bot commented Apr 16, 2026 •

edited

Loading

DarkoKukovec May 12, 2026 •

edited

Loading