We had similar thoughts! This is more or less how Script Sync works today - with the caveat that we only allow it within Folder / Script root instances.
This approach is great for compatibility - it means you rarely need to restructure your project to use Script Sync, but we do see some problems emerge. Particularly when using an external version control system:
In situations when you want to start sync from the disk state from a new branch, scripts in the DM that are not present on the disk will get deleted. Instances script sync does not recognize are ignored. This may be expected behavior in some cases, but it also leads to situations when you get a mixture of old / new instances.
In cases where you have ‘ignored’ instances underneath a Script, those Instances would get deleted when you ‘load from disk’ along with the Script. You might try to recover these by going back to a different commit, but as there’s no trace of these Instances on the disk this would not work.
It is hard to recognize ‘renames’ / ‘moves’ on the file system. Applications (including Studio Script Sync) generally observe these as a ‘delete + create’. If you move around a file / directory that is synced with an Instance with ignored instance descendants, we have to Stop Sync to prevent those ignored descendants from being deleted. There are ways to improve this, but they are complex.
There’s two ways of looking at this problem:
We’re already supporting syncing Folders with non-script instances, so we have all of these problems already. We should just lean into it and support Services, and trust the user will figure out these quirks for themselves.
We should ‘stop digging’ and try to encourage users to organize their scripts separately from the DM.
Both approaches have merits, and naturally we want to respect creators choices and empower them to work the way they want to work. We need to put some more thought into the right path forwards.
In a recent meeting - Script Sync’s lead engineer remarked ‘Script Sync had great, clean code, until I started work on init.luau support’. We have had many discussions at Roblox about how ‘init.luau makes everything harder’.
The background on ‘init’, was it was a convention set by Rojo ~8 years ago. Given Rojo’s dominant role in the ‘file-based Roblox code’ ecosystem, the pattern became very common.
Briefly - we discussed ripping the band aid off and changing this behavior to something that worked more naturally, but ultimately we decided against doing this. Our view was that ‘breaking convention’ here would create incompatibilities between Script Sync and Rojo and we felt this would be unhelpful for our users.
I didn’t know that this project will become a “native Rojo” for Studio. I thought for a better alternative for Rojo, I used Rojo many times on many projects but I never like it when I am using it. Establishing a Rojo project with a custom structure was always been a pain with it.
But with this native sync update a lot of things became easy to do.
I dislike the idea of limiting capabilities of this feature with Rojo Structures.
I started using Argon - Full featured tool for Roblox development
I guess it is based on Rojo but it has some feature that Rojo does not have
First one it mirrors exact folder structure as in Studio so src/ReplicatedStorage src/ServerStorage etc
Also one of excelent features is that it has INITIAL phase where you can choose if initial sync is from Studio or from VS Code (server)
I use this to sync complete project that was initially done in Studio then sync everything to disk , this feature does not exist in Rojo and it is essencial for me
Good point about the initial sync - I guess one way to handle it would be to ask the user in this case, as if, for example, they are using git on the filesystem copy, then it would make sense to just sync from studio to filesystem and delete any script which aren’t in studio, which will give the user a ‘current’ copy but also to allow the user to run diffing against the current git state. of course the user could choose the opposite which would copy from filesystem to roblox in which case they’re responsible
For the ‘ignored’ instances, I’d just say leave them there as they are outside of the scope of the sync. The user might need to clean them up manually but it’s better than accidentally deleting something the user wants to keep.
For renames and moves - I don’t think there’s a problem with delete + create, but it’s definitely a tricky case that will need to be handled carefully.
And for the 2 ways of looking at the problem - I would strongly recommend 1 because a) you’re half way there and b) this is kinda the roblox way where the initial tutorials talk about putting scripts on objects etc, rather than keeping the entire script tree separate. although if there was an easy way to integrate that external script tree then that would also be an option. please don’t stop digging when you’re so close!
Oh! I got really confused for a bit–thought “Archetype: Earth” was some intentionally-vague error code, but it was actually one of our script’s names. Would definitely appreciate it being more clear on that
Just want to give some props to the directory sync feature, it’s been AWESOME! I was crashing into the previous individual script limit, but with this I’ve been able to add everything with ease. No longer needing to sync every new script added really streamlines my workflow. Thanks for adding this!
I’d say it’d be really nice to have a way to sync every script in your game, like rbx-to-rojo does and then using Rojo. currently, i’m sticking with rojo, but the future of this looks bright!
They persist through every session