This isn’t a Feature Request, per se. I’d like to suggest a conceptual method for splitting anvil.yaml into functional parts, to help support those who have to maintain multiple instances of a large, complex app.
The core idea can be found here:
In this way, developers could decide for themselves which app features are to be common among all instances of an app (e.g., selected tables; secrets; …), and which will depend on other factors (e.g., dev vs. test. vs. production; app version v1 vs v1.1 vs v2; …).
I think this is probably a good way to get the dependencies right. I’m not so sure about how this would affect the structure or content of the project file(s). I at least wanted to get the idea out there, so that brighter and/or more experienced minds could suggest a practical approach.
Unfortunately anvil.yaml is maintained by the Anvil Editor, so if you edit your app at all you’ll find it “snaps back” to the layout it started with (eg comments aren’t preserved).
Our medium-term goal is that you shouldn’t need to edit anvil.yaml at all when you push/pull code between multiple instances (eg dev/prod). The FR you link to describes one exception to that rule – if you have any more, please post FRs for “stop me having to edit anvil.yaml between instances”
I don’t have a concrete Feature Request yet. Rather, I want to collect ideas for one, ideas that have been vetted as good practice elsewhere in the software development industry.
Hence, the “how to think” title. I mean it literally. Once we’re sure how to think about it, then we can establish requirements, think about practical mechanisms, and thereby arrive at a good Feature Request.
Maybe it won’t ever get to the level of quality I’d want to put into a Feature Request. But it should help me understand what I’m doing better, when I get to the stage where I and my app are one of those “exceptions”. I expect to get to that point fairly soon…
