portless : remplacer les numéros de port par des URL locales nommées
Remplacez les numéros de port par des URL locales stables et nommées. Pour les humains et les agents.
En bref
- De quoi s’agit-il ?
- Des URL nommées stables pour le développement local, pour les humains et les agents.
- À qui s’adresse-t-il ?
- Portless propose une approche concrète des URL de développement local, mais le README ne traite pas de benchmarks de performance, de garanties de sécurité au-delà du comportement TLS par défaut, ni de préparation à la production. Le projet est en pré-1.0 et le format du répertoire d'état peut changer.
- Puis-je l’utiliser commercialement ?
- Oui. Apache-2.0 est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
- Est-il encore maintenu ?
- Oui. Les derniers commits datent d’il y a 1 jour.
- En quel langage est-il écrit ?
- Principalement TypeScript, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 15 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Ce que portless remplace
Portless remplace les numéros de port dans les URL de développement local par des adresses nommées stables. Au lieu de vous souvenir que votre application tourne sur http://localhost:3000, vous obtenez https://myapp.localhost. Le projet se décrit comme fonctionnant pour les humains et les agents, ce qui signifie que les URL nommées sont destinées à être plus faciles à taper pour les humains et à référencer pour les outils automatisés. Le README montre un changement typique : next dev devient portless run next dev, et l'URL de sortie est basée sur le nom d'application que vous fournissez.
Installation et exigences système
Installez portless globalement avec npm install -g portless, ou comme dépendance de développement de projet avec npm install -D portless. Le README note que le projet est pré-1.0, donc des installations par projet peuvent conduire différents contributeurs à exécuter des versions différentes, et le format du répertoire d'état peut changer entre les versions, ce qui peut nécessiter de relancer portless trust. Les exigences indiquées sont Node.js 24+ et macOS, Linux ou Windows. Les CLI Tailscale et ngrok sont optionnelles et ne sont nécessaires que pour les fonctionnalités de partage.
Configuration : portless.json et clé package.json
Un portless nu exécute le script dev de package.json via le proxy, en déduisant le nom de l'application à partir du nom du paquet, de la racine git ou du répertoire. Vous pouvez remplacer le nom avec un fichier portless.json contenant un champ name. Le script par défaut est dev. Pour les monorepos, un seul portless.json à la racine du dépôt couvre tous les paquets de l'espace de travail, découverts à partir de pnpm-workspace.yaml ou du champ workspaces dans package.json. La map apps permet des remplacements de nom par paquet, et les noms d'hôte suivent une convention <package>.<project>.localhost, sauf si un paquet correspond au nom du projet. Alternativement, une clé "portless" dans package.json peut définir le nom ou des options par application, avec priorité sur les entrées portless.json mais remplacée par les drapeaux CLI.
Routes nommées, sous-domaines et worktrees
Portless attribue un port libre dans la plage 4000-4999 à chaque application et l'enregistre auprès du proxy. Vous pouvez spécifier un nom et une commande, comme portless api.myapp pnpm start, pour obtenir https://api.myapp.localhost. Par défaut, seuls les sous-domaines explicitement enregistrés sont routés ; --wildcard permet à tout sous-domaine de retomber sur l'application parente. Les worktrees Git sont détectés automatiquement : un worktree lié reçoit le nom de branche comme préfixe de sous-domaine, donc chaque worktree a sa propre URL sans configuration supplémentaire. Utilisez --name pour remplacer le nom de base tout en conservant le préfixe du worktree.
HTTPS, AC locale et TLD personnalisés
HTTPS avec HTTP/2 est activé par défaut. Au premier lancement, portless génère une AC locale, la fait confiance et lie le port 443, avec élévation automatique via sudo sur macOS et Linux. Utilisez --no-tls pour du HTTP simple. Le proxy démarre automatiquement lorsque vous exécutez une application et réutilise la configuration du dernier lancement, sauf si elle est remplacée par des variables d'environnement. Les TLD personnalisés sont pris en charge via --tld, par exemple .test, et le proxy synchronise automatiquement /etc/hosts pour les noms d'hôte des routes. Les TLD multi-segments comme dev.example.com sont autorisés, ce qui peut garder les URI de redirection OAuth et les cookies cohérents avec la production. Le README recommande .test et met en garde contre .local et .dev pour des raisons techniques spécifiques.
Partager les serveurs de développement
Portless propose trois modes de partage. Le mode LAN (--lan) lie le proxy à toutes les interfaces et utilise mDNS pour publier des noms .local sur le réseau local, avec détection automatique de l'IP LAN. Le partage Tailscale (--tailscale) monte chaque application sur son propre port HTTPS dans votre tailnet, en utilisant vos certificats HTTPS Tailscale existants. Funnel (--funnel) expose l'application à l'Internet public via Tailscale Funnel. Le partage ngrok (--ngrok) crée une URL publique via ngrok. Chaque mode a ses propres prérequis : CLI Tailscale et certificats HTTPS activés pour Tailscale, CLI ngrok et authentification pour ngrok, et outils mDNS (avahi-utils sur Linux) pour le mode LAN. Des variables d'environnement comme PORTLESS_LAN=1 peuvent définir un mode par défaut.
Commandes opérationnelles et nettoyage
L'ensemble de commandes comprend portless run pour déduire le nom, portless alias pour les routes statiques, portless list pour afficher les routes actives, portless doctor pour les diagnostics, portless trust pour installer l'AC, portless clean pour supprimer tout l'état et les entrées de confiance, et portless prune pour tuer les processus orphelins. Il existe également des commandes de contrôle du proxy : portless proxy start, stop, et des options comme --port, --no-tls, --foreground et --wildcard. Un service peut être installé avec portless service install pour démarrer le proxy au démarrage du système en utilisant launchd, systemd ou le Planificateur de tâches. Le README inclut une liste de variables d'environnement qui remplacent les paramètres du proxy et des variables injectées dans les processus enfants, telles que PORT et PORTLESS_URL. Pour désactiver portless pour un seul lancement, définissez PORTLESS=0.
Conclusion éditoriale
Portless propose une approche concrète des URL de développement local, mais le README ne traite pas de benchmarks de performance, de garanties de sécurité au-delà du comportement TLS par défaut, ni de préparation à la production. Le projet est en pré-1.0 et le format du répertoire d'état peut changer. Les utilisateurs doivent vérifier le comportement de confiance de l'AC et les détails spécifiques à la plateforme sur leurs propres systèmes.
Notes de la communauté