feat(dev): optional per-developer overrides via dev-local.yaml

[rjmunro]

About the Contributor

This pull request is posted on behalf of SuperFly.tv.

Type of Contribution

This is a:

Feature / Documentation improvement

Current Behavior

Long yarn dev sessions can grow Node heaps unboundedly (especially TSC and Vite).
Developers who want LAN access to the Vite UI also have to patch tracked config or run
Vite by hand. Personal tweaks were often kept in stashes or one-off package.json
edits that are easy to commit by mistake.

A uniform NODE_OPTIONS / TOOL_NODE_FLAGS in the shell already works for a single
shared heap limit, but not for different per-process limits or Vite --host.

New Behavior

Optional gitignored dev-local.yaml (same idea as meteor-settings.json) is loaded by
scripts/run.mjs when present:

• Per-process Node memory caps for TSC, Meteor (tool + app), and Vite
• Optional Vite --host for LAN access

Copy dev-local.example.yaml → dev-local.yaml and edit. Documented in DEVELOPER.md
and yarn dev --help.

yaml is declared as a root devDependency so we do not rely on transitive hoisting.
It was already present in the tree via lint-staged — the yarn.lock delta is a
single line adding it to the workspace dependency list (no new package resolution).

Testing

• I have added one or more unit tests for this PR
• I have updated the relevant unit tests
• No unit test changes are needed for this PR

Affected areas

• Local development only (yarn dev / yarn start orchestration)
• No runtime / production behaviour change when dev-local.yaml is absent

Time Frame

Not urgent — quality-of-life for local development; fine for the in-development release.

Other Information

Example:

cp dev-local.example.yaml dev-local.yaml
# edit memory limits / vite.host as needed
yarn dev
# logs: Found dev-local.yaml

Status

• PR is ready to be reviewed.
• The functionality has been tested by the author.
• Relevant unit tests has been added / updated.
• Relevant documentation (code comments, system documentation) has been added / updated.

[coderabbitai]

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 69b6a202-36c4-48b5-93d5-7104dca333ce

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[Julusian]

This has overlap with the env file I have as part of #1786
I dont have a strong preference on whether to go with a yaml or env file.

One thing we are visibly disagreeing on is how the example file should work. I went with an approach of that the example should be documentation and shouldnt do anything until something is enabled. You have an approach of the env file being setup with some suggestions that someone may want to disable almost all of. I see it as an example file to me is a suggestion of how to setup your local env, so to me only things that we recommend be set should be set there. (In some projects I have seen it where they will auto-copy the example to a usable one for you if it doesnt exist)

I like the simplicity of the envfile format, partly as it doesn't need a library to load, just invoking node with node --env-file-if-exists=.env . But it is less readable than something structured like yaml.

same idea as meteor-settings.json

Worth noting that this is no longer really used (although I appear to have missed a few references)

[nytamin]

We'll close this one for now, and keep the idea in mind for later (after the major de-Meteor-merge PRs)