-
There are a few threads on here mostly from the perspective of using vercel dev in CI or a container. (The solution to which is using token). However, I question why this is needed at all. I understand logging in and linking to a project gives access to env variables but barring that it feels a bit like a dark pattern. It's bizarre when you're working on something 100% local and being force to interact with an online service to be allowed to do so. There are numerous cases where a developer wouldn't want to login and/or link their local environment to a vercel project: working without an internet connection, experimenting on something that you don't want to deploy yet or ever, working on a project without access to a vercel team, contributing to an open source project you don't want to link a personal vercel project, etc. I think the simplest solution would just be to add an offline flag or something to the dev command that bypasses the login/linking requirements. |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments
-
Update: The CLI team is currently working on a feature to address this need #8761 (comment) Thanks for sharing this perspective! Log in is needed for access to all project settings, including env vars as you mentioned, which are needed for accurate builds. I suspect that adds some difficulty to enabling disconnected builds. The examples you listed do make a lot of sense, and I'm changing this to a feature suggestion for the team to explore. |
Beta Was this translation helpful? Give feedback.
-
@amyegan Thank you for your response! I've added a PR with a basic implementation of this idea but am unable to run the needed unit tests locally: #8761 |
Beta Was this translation helpful? Give feedback.
Update: The CLI team is currently working on a feature to address this need #8761 (comment)
Thanks for sharing this perspective! Log in is needed for access to all project settings, including env vars as you mentioned, which are needed for accurate builds. I suspect that adds some difficulty to enabling disconnected builds. The examples you listed do make a lot of sense, and I'm changing this to a feature suggestion for the team to explore.