Just a few days ago, inspired by [1], I had begun transitioning my justfiles and shell scripts to gleam code in $PROJECT_ROOT/dev. The timing of —no-print-progress flag landing in this release feels like the cosmos validating my choice :)
Oh that's a nice read! I tend to have a bin directory with a bunch of shell scripts for each project and use direnv to add it to the path when I'm inside that project
Yours is surely the standard and less time-consuming way. I just had an itch to avoid an additional shell-hook accessing/manipulating environment variables on every directory change. I figured, as long as there exists a gleam.toml in the project root, gleam dev can find the correct files to run; and so, I can shoehorn it as a task runner. Moreover, I can extract the common workloads to a local or git dependency. Ultimately, I'm just bike-shedding but it's okay to have guilty-pleasures now and then :)
In a gleam project you can have three main folders with code: src, for your source code; test, for test code; and dev. Much like test, the code under dev can use dev dependencies, and is not included in your production app. Under dev you'll find all sort of code useful at development time: stuff like benchmarks, code generation scripts, dev servers, and so on...
I can't believe I've been writing Gleam for years and I've only just learnt about this. I'll have to go back to all my projects and remove the codegen modules I created, thanks!
mhm | a day ago
Just a few days ago, inspired by [1], I had begun transitioning my
justfilesand shell scripts to gleam code in$PROJECT_ROOT/dev. The timing of—no-print-progressflag landing in this release feels like the cosmos validating my choice :)Grazie mille!
1: https://matklad.github.io/2026/01/27/make-ts.html
[OP] giacomo_cavalieri | a day ago
Oh that's a nice read! I tend to have a
bindirectory with a bunch of shell scripts for each project and usedirenvto add it to the path when I'm inside that projectmhm | a day ago
Yours is surely the standard and less time-consuming way. I just had an itch to avoid an additional shell-hook accessing/manipulating environment variables on every directory change. I figured, as long as there exists a
gleam.tomlin the project root,gleam devcan find the correct files to run; and so, I can shoehorn it as a task runner. Moreover, I can extract the common workloads to a local or git dependency. Ultimately, I'm just bike-shedding but it's okay to have guilty-pleasures now and then :)[OP] giacomo_cavalieri | a day ago
Oh sure the hacks and guilty pleasures are what make programming fun!!
zmitchell | a day ago
I somehow didn’t know that the
gleam devcommand existed.I, uh, don’t know what this means lol What do people use it for?
[OP] giacomo_cavalieri | a day ago
In a gleam project you can have three main folders with code: src, for your source code; test, for test code; and dev. Much like test, the code under dev can use dev dependencies, and is not included in your production app. Under dev you'll find all sort of code useful at development time: stuff like benchmarks, code generation scripts, dev servers, and so on...
Hasnep | 21 hours ago
I can't believe I've been writing Gleam for years and I've only just learnt about this. I'll have to go back to all my projects and remove the codegen modules I created, thanks!