I agree with this. If I wanted to make progress right now, I’d definitely go with the option of doing things myself. That’s very much in the spirit of using Glitch.
Good point, that’s a question that I think hasn’t thoroughly been answered in the context of static projects. That question is going to be more valuable now that this huge ‘feature’ for static projects has just landed and will be drawing more attention to it.
Most of the literature on the directory is about (i) it’s excluded from verison control by default and (ii) it’s not copied on fork. (Ah, I forgot to mention that these “record.txt” files don’t need to be copied on fork.) And I’ve made a few posts on this forum about whether or not it lives up to the description of “private” ~mostly with staff agreeing to put protections in place similar to .env.
True fact, and a useful thing to bring up for anyone else reading this. In my case there are many files with a janky script to rotate older ones to different names and stuff, so I think it’ll be neater to shove them all in a directory and have an unchanging .gitignore file.
Thanks for y’all’s concerns about my specific project. I have some ideas of what to do to fix it for myself, although I haven’t committed to putting forth the time to do it yet.
The feedback still stands as feedback though:
- there’s now a weird difference in how static projects are served between when the project container is running and when the project container is not running
- the behavior when the project container is not running breaks some normal-ish behavior (I’m trying to maintain that symlinks are normal)