This One File Fixed My Dev Environment (Devbox)

EnglishالعربيةDeutschEspañolFrançaisहिन्दीBahasa Indonesia日本語한국어PortuguêsРусский中文
BBetter Stack
Computing/SoftwareSmall Business/StartupsInternet Technology

Transcript

00:00:00your readme is lying to you it says setup takes five minutes then node is wrong python is wrong
00:00:07postgres is missing docker is taking forever and now we're debugging before we even get started
00:00:13your dev environment should not live in a readme it should live in git that's what devbox does
00:00:20one devbox json file one command devox shell same environment for every dev with no global installs
00:00:28and no nix knowledge required let me show you
00:00:30at first devbox looks almost too simple you make a devbox json you list the tools your project needs
00:00:42node go python postgres whatever your stack actually needs you commit that file then anyone else can just
00:00:50run devbox shell and they get the same environment you do same versions tools scripts no global
00:00:58installs no please install these eight things first no homebrew state from years ago your setup
00:01:03stops living in someone's memory it starts living in your repo now that sounds small but if you've
00:01:09ever lost half a day to a broken local setup you already know that this is not small if you enjoy
00:01:16coding tools to speed up your workflow be sure to subscribe we have videos coming out all the time
00:01:20now we're starting off here so i'm going to start with an empty project i'm going to make a new folder
00:01:25we'll call it devbox demo we cd into the folder and all we need to do once we have devbox is run
00:01:31devbox in it devbox creates a file called devbox json right now it's basically empty it's just the
00:01:39boilerplate that devbox gives us now let's add the tools this project actually needs to add tools we can
00:01:45create a devbox add and i'm going to install things like go node.js and some python now here's the
00:01:52important part i'm not installing these globally i'm not changing my system node i'm not touching my system
00:02:00with python these tools belong to this project now when i run devbox shell and i'm inside a clean project
00:02:09environment now that you're in this environment you could just check the versions right go version no
00:02:14version python version right i can check everything to make sure it's running now that's the big payoff
00:02:19the project asked for specific tools devbox gave me those tools now let's add a script and inside devbox
00:02:27json we can actually define a test and i'm just going to echo back these running tests and i'll get the node
00:02:34in the go version when you run devbox run test and now that same command works for anyone using this repo
00:02:42same script same tools same environment now watch what happens when i leave you can just run exit
00:02:48you are going to leave that environment and i'm back to my normal machine environment so that was a dead
00:02:53simple right like what is devbox actually doing well devbox uses nyx under it all nyx is great because
00:03:00it's built for reproducibility instead of saying install whatever happens to be the latest today
00:03:06it can pin the exact tools your project actually needs now that is the good part the hard part is
00:03:12that nyx can feel like a whole new world there are a lot of concepts that are great but not exactly
00:03:18friendly when all you wanted was the right node version devbox takes shows us something different
00:03:23here it says what if we kept the reproducibility but made the workflow feel normal so instead of
00:03:29writing nyx expressions you can use commands like devbox add devbox search shell run services all of
00:03:37these commands are much more simpler and your project gets two important files you get a json file and a
00:03:44lock file think of the devbox json as what our environment needs think of the devbox lock file as the pin to pin
00:03:52exactly what you got you commit both now your environment is not just a paragraph in a readme file
00:03:58it's part of the actual project devbox works on mac os linux and wsl it can integrate with vs code it can
00:04:06define scripts it can manage services like databases and when you need to it can export to things like
00:04:12docker dev containers and ci workflows the value of this isn't just cool tool right it's a dead simple tool the
00:04:19value is i think just time the first problem is the readme right the readme could say really anything it
00:04:26could say hey install node 18 but the app has changed it really needs node 20. the second problem
00:04:32this actually helps with is onboarding it's your first day on the job it should be easy to get going
00:04:37we know that's not the case right so you shouldn't need to ask which node version do i need you shouldn't
00:04:43need to ping someone hey which python version are we on do i really need postgres locally and why does
00:04:48this only work for little timmy over there they should just have to clone the repo enter the shell
00:04:52and run the project if something breaks at least everyone is starting from the same environment the problem
00:04:58is global pollution trying tools should not wreck your laptop you want go 1.22 for this repo you add it you
00:05:06want node 20 here but something else elsewhere fine okay that's fine the tools live with the project your
00:05:13system stays cleaner with devbox your environment definition can be shared between local development
00:05:18and automation does that fix every ci problem no it's not going to but it removes a huge class of dumb
00:05:26problems and dumb problems are the ones that hurt us the most they're simple we still have them all the
00:05:32time finally here is docker heavy local docker workflow more specifically docker is still great by far if
00:05:40you need containers use containers but a lot of teams use docker locally because they don't have a better
00:05:46way to manage tools now what's good here is the workflow is dead simple dev box add shell run you
00:05:52don't have to learn that much the environment becomes a real part of your project a real file
00:05:57in the repo when everyone uses the same versions and scripts debugging gets easier but that's great
00:06:03super simple what's going to annoy you is well the first next door download it took a while to download
00:06:09it's fine it's the first time okay json is simple but it can get ugly as we know if we add too much
00:06:15into it for basic scripts it's fine for complex setup logic don't cram a giant shell command into json
00:06:22just put the logic in a sh file then call that from dev box and finally dev box is not a full cloud ide
00:06:30if you need browser-based coding instant preview urls you may still want something like code spaces
00:06:36dev box is best at local and ci reproducibility dev box is not going to solve every development
00:06:42problem but it can solve the ones that annoy us the most which is really just getting the project to
00:06:46run so could be worth a shot especially if your project has more than one language or more than
00:06:51one cli tool if you enjoy coding tools like this be sure to subscribe to the better stack channel we'll
00:06:56We'll see you in another video.

Key Takeaway

Devbox eliminates inconsistent development environments by using a devbox.json file to lock project-specific tool versions, ensuring that every contributor runs the exact same setup with a single command.

Highlights

  • Devbox replaces inconsistent README-based setup instructions by pinning project-specific tool versions in a devbox.json file.

  • Commands like devbox add, devbox shell, and devbox run allow developers to manage dependencies without global system installs or complex Nix configurations.

  • The devbox.lock file ensures reproducible environments by pinning the exact versions of required tools across all team members.

  • Devbox supports macOS, Linux, and WSL environments and integrates with VS Code for local development.

  • Devbox exports configurations to Docker and CI workflows to maintain consistency between local development and production automation.

  • Moving environment definitions into a repository reduces onboarding time and eliminates issues related to system-level global dependency pollution.

Timeline

Problems with Traditional Setup Methods

  • README-based setup instructions often become outdated or incomplete.
  • Global software installations lead to system pollution and conflicting version requirements.
  • Debugging local environment issues frequently consumes significant developer time.

README files often fail because they rely on human memory and outdated system states. Global installs for tools like Node, Python, or Postgres often clash with other projects, leading to broken setups. Moving environment management into the git repository itself creates a source of truth that all developers can rely on.

Implementing Devbox for Project Environments

  • Initializing a project with devbox init creates a devbox.json configuration file.
  • The devbox add command installs project-specific dependencies without modifying the global system.
  • Running devbox shell creates an isolated environment with the exact tools and versions required by the project.

After creating a new directory, developers initialize Devbox to generate the configuration file. Tools are added specifically to that project, ensuring that system versions of Python or Go remain untouched. Once the shell is activated, all specified tools are immediately available and isolated from the rest of the host machine.

Reproducibility and Workflow Integration

  • Devbox uses the Nix package manager to pin specific tool versions.
  • The system generates a devbox.json and a devbox.lock file to ensure reproducibility.
  • Scripts can be defined directly in devbox.json and executed consistently using devbox run.

Devbox abstracts the complexity of Nix, providing a user-friendly interface to manage environments. By committing the lock file, teams ensure every member uses the exact same tool versions. These configurations can also be integrated into Docker containers and CI pipelines to bridge the gap between local development and deployment.

Limitations and Considerations

  • Initial setup and first-time downloads can be time-consuming.
  • Complex shell logic should be moved to external script files rather than inside the JSON configuration.
  • Devbox is designed for local and CI reproducibility and does not replace cloud IDE platforms.

While Devbox solves environmental consistency, it requires an initial download for the Nix packages. Users should avoid overcrowding the configuration file with complex commands, opting instead to call external shell files. It remains a tool for local development rather than a full browser-based IDE solution.

Community Posts

No posts yet. Be the first to write about this video!

Write about this video