Framed is a CLI tool that simplifies the organization and management of files and directories in a reusable and architectural manner. It provides YAML templates for defining project structures and enables workflows based on those.
To always be in sync with the YAML template, Framed provides a built-in test command that can be used in CI/CD pipelines to verify the project structure.
It was just a project to learn some golang, but i think that the idea is quite nice. Let me know what do you think.
Hey, congrats on shipping it. Let me run this by you:
I was just thinking of building a CLI tool that I can say “start me a X lang project”, with my preferred dir layout, files and default dependencies. Basically a “react-create-app” or “bundle init” for any language.
Is Framed a solution for that? From what I saw there’s no default file contents and ability to run commands?
There is Framed import command, where you can import framed file from specific url/examples. Then if you would execute Framed create it will create dirs and file structure. In the future I would imagine that there will be more examples files in the repo so you would be able to do f.e framed import —examples react.
CookieCutter is the typical solution for for this.
An alternative is "uPlaybook": https://github.com/linsomniac/uplaybook (disclaimer, I'm the author). It is a YAML-based simple scripting that is focused on simple CLI-based automation, in particular file templating and secrets decryption.
uPlaybook is a small Ansible+CookieCutter combination. In the uPlaybook you can do simple shell-like operations, create files based on jinja2 templates, decrypt secrets, and do some looping/conditionals.
You can define parameters that the user needs to supply (for your "react-create-app" that might be app name, features you might optionally want), which uPlaybook turns into CLI arguments, or it can prompt the user to fill them out.
I'd be interested if the author could elaborate on use-cases for this. It seems like a nice bit of automation, but for a problem that I don't think I've ever had.
I've worked on a relatively big startup codebase with a lot of common patterns, but directory management wasn't a problem that we had. I've also worked in the Google monolith, and while there are a lot of defined practices, in my experience this isn't quite the tool we'd need to manage them (things like ownership matter more).
For me there are two main use cases. First is when you have multiple small repos in the project and you want them to be coherent, you would use shared config file and enforce the structure on ci. Second would be to import best-practice config files to quickly start the project with pre defined dirs/files structure.
Couldn't you just create a project template for this?
Don't get me wrong, I think you created a neat project there and it surely has some use, but the argument that this adds a lot of complexity without solving a problem that justifies that kind of complexity stands.
You are correct, especially for smaller project it might add unnecessary complexity, however I still think that for larger ones it might be useful. I’m still trying to figure out which direction should I go with this so thanks for your feedback!
I understand it at this level, but I'm not sure what coherence there is that's necessary to get.
I can understand, for example, all the Python libraries in the company nesting code under src/ and test/, but that's fairly easy to see and likely never changes after project creation. It's also not really that impactful to dev experience in my experience. Going much further than this feels like it would get too project specific quickly and provide less value.
Do you have examples of the sorts of rules you've seen have most impact?
I looked at this an hour ago before I started work and thought it was silly. I then opened one of my work projects and started looking for a specific file that I know is in the wrong place but there's never been a good time to move it.
I see the value.
This could do with tests though, and the business logic could be in a different package that the cmd folder uses.
16 comments
[ 17.1 ms ] story [ 44.3 ms ] threadI was just thinking of building a CLI tool that I can say “start me a X lang project”, with my preferred dir layout, files and default dependencies. Basically a “react-create-app” or “bundle init” for any language.
Is Framed a solution for that? From what I saw there’s no default file contents and ability to run commands?
An alternative is "uPlaybook": https://github.com/linsomniac/uplaybook (disclaimer, I'm the author). It is a YAML-based simple scripting that is focused on simple CLI-based automation, in particular file templating and secrets decryption.
uPlaybook is a small Ansible+CookieCutter combination. In the uPlaybook you can do simple shell-like operations, create files based on jinja2 templates, decrypt secrets, and do some looping/conditionals.
You can define parameters that the user needs to supply (for your "react-create-app" that might be app name, features you might optionally want), which uPlaybook turns into CLI arguments, or it can prompt the user to fill them out.
I've worked on a relatively big startup codebase with a lot of common patterns, but directory management wasn't a problem that we had. I've also worked in the Google monolith, and while there are a lot of defined practices, in my experience this isn't quite the tool we'd need to manage them (things like ownership matter more).
Don't get me wrong, I think you created a neat project there and it surely has some use, but the argument that this adds a lot of complexity without solving a problem that justifies that kind of complexity stands.
I can understand, for example, all the Python libraries in the company nesting code under src/ and test/, but that's fairly easy to see and likely never changes after project creation. It's also not really that impactful to dev experience in my experience. Going much further than this feels like it would get too project specific quickly and provide less value.
Do you have examples of the sorts of rules you've seen have most impact?
I see the value.
This could do with tests though, and the business logic could be in a different package that the cmd folder uses.
https://github.com/marketplace/actions/mactat-framed
https://github.com/mactat/framed-action