Charger .envrc ou mise.toml avant de démarrer un service

Votre projet dépend de direnv, mise ou asdf pour gérer ses variables d'environnement, ses secrets et ses versions d'outils. Dans un terminal tout fonctionne parce que les hooks d'init de votre shell s'occupent du chargement. Runyard, lui, démarre votre service avec un environnement vierge : aucun de ces hooks ne se déclenche, et le service tourne avec une configuration manquante ou périmée.

Le piège

direnv et mise exposent tous deux une sous-commande exec qui applique l'env propre au projet à un processus enfant, sans aucun hook shell. Vous encapsulez votre vraie commande avec. asdf n'a pas d'équivalent propre, donc pour asdf la voie la plus simple reste d'encapsuler la commande dans un shell de connexion.

Configuration qui fonctionne

direnv

{
  "name": "API",
  "type": "service",
  "directory": "~/Code/votre-projet",
  "startCommands": [{
    "label": "Dev",
    "command": "direnv",
    "args": ["exec", ".", "npm", "run", "dev"]
  }],
  "paths": ["/opt/homebrew/bin"]
}

direnv exec <chemin> <cmd...> charge <chemin>/.envrc, applique ses variables, puis exécute cmd dans cet environnement. Le . signifie « utilise le répertoire courant » (qui est le directory de l'outil).

mise

{
  "startCommands": [{
    "label": "Dev",
    "command": "mise",
    "args": ["exec", "--", "npm", "run", "dev"]
  }]
}

mise exec -- <cmd...> applique les versions d'outils et l'env du projet définis dans mise.toml ou .mise.toml, puis exécute cmd. Le séparateur -- est requis : sans lui, mise tente d'interpréter npm run dev comme ses propres drapeaux.

asdf (sans exec natif)

asdf n'expose pas de sous-commande exec, alors on revient au schéma du shell de connexion. Assurez-vous que le répertoire des shims d'asdf est dans paths, ou chargé par votre shell de connexion.

{
  "startCommands": [{
    "label": "Dev",
    "command": "/bin/zsh",
    "args": ["-lc", "npm run dev"]
  }]
}

Pourquoi ça fonctionne

• direnv exec et mise exec sont de purs lanceurs de processus enfant. Ils lisent les fichiers du projet, construisent un env, puis font un execve vers votre commande. Aucune interaction avec un shell, aucun fichier d'init.
• Le répertoire de travail est fixé par Runyard à partir du directory de l'outil, donc direnv / mise cherchent au bon endroit.
• Pour asdf, le shell de connexion charge ~/.asdf/asdf.sh depuis votre .zshrc, ce qui met en place les shims pour que les bonnes versions soient utilisées.

Prérequis

• direnv, mise ou asdf installé (en général via Homebrew : brew install direnv mise asdf)
• Le répertoire du binaire dans le tableau paths de Runyard pour que la commande soit résolue. /opt/homebrew/bin couvre l'installation Homebrew sur Apple Silicon.
• Pour direnv uniquement : exécutez direnv allow une fois dans un terminal, à l'intérieur du projet. direnv refuse de charger un .envrc non approuvé. C'est une sécurité, pas une bizarrerie de Runyard. Sans cette étape, le service démarre mais les variables d'env restent absentes.
• Pour mise uniquement : assurez-vous que le mise.toml du projet est versionné et que tous les outils requis sont déjà installés (mise install).

Piège : l'invite direnv allow est invisible depuis Runyard

direnv invite normalement dans le terminal quand il détecte un .envrc nouveau ou modifié. À l'intérieur de Runyard, il n'y a pas de terminal pour cette invite : direnv journalise un « blocked » silencieusement et utilise l'env du parent à la place. Si votre service démarre mais se comporte comme si les variables d'env étaient absentes, ouvrez un terminal dans le répertoire du projet et exécutez direnv status.