Currently, Azul does not take into account filesystem changes. The intended workflow is to work in Studio, with your filesystem acting as a read-only mirror. This aligns with the core philosophy of the tool (just like how Rojo inversely does not replicate Studio changes back to the filesystem).
However, the expectation is that Azul should handle both cases. By far, the most requested Azul feature is to allow for fileystem actions to replicate back to Studio.
Benefits
- More integrated experience across all IDEs.
- Pushing will no longer be needed as often, since one can just place files directly in the sync folder.
Drawbacks
- Breaks the main philosophy of the tool.
- Overhead: Azul will need to track new file creations, deletions, renames, type renames
- Allowing this will set a precedent that files can "just be dropped in", which will cause confusion when trying to import non-Azul code (Rojo projects, Wally packages, other code that assumes
init.luau pattern...).
Currently, Azul does not take into account filesystem changes. The intended workflow is to work in Studio, with your filesystem acting as a read-only mirror. This aligns with the core philosophy of the tool (just like how Rojo inversely does not replicate Studio changes back to the filesystem).
However, the expectation is that Azul should handle both cases. By far, the most requested Azul feature is to allow for fileystem actions to replicate back to Studio.
Benefits
Drawbacks
init.luaupattern...).