manifest.json makes no-op changes on disk very frequently

[amonks]

Thanks for your work on this extension! It's very useful.

I'd like to share user scripts between machines by committing the data folder to my dotfiles repo. I observe that the manifest.json file in this folder[1] changes on disk every few minutes, even when I'm not interacting with the extension, and the changes only vary the json key order (which seems to me like it ought to be a no-op).

[1]: Library/Containers/com.userscripts.macos.Userscripts-Extension/Data/Documents/manifest.json

1. I'm a bit curious what behavior is causing this file to thrash in the first place — I'm surprised that the extension needs to write this file in the background at all (writing the file in response to interaction would not be surprising) — maybe this is a bug?
2. If this background process is necessary and not a bug, I wonder if setting encoder.outputFormatting = [.prettyPrinted, .sortedKeys] here would do the trick

[ACTCD]

For the first point, it's not a bug, but it is indeed one of the issues that should be addressed when we plan to update the backend process in the future.

Essentially, it was introduced in #525. When you focus the Safari window, it checks the script files for changes in the background and updates the manifest file. So if you don't switch focus to Safari, that won't happen.

For the second point, that might keep the file contents from changing (in the case you describe), but probably won't avoid the fact that the file is written.

A better approach might be to stop writing to the file when it's confirmed that nothing has changed, but that might require some process refactoring.

One problem is that currently the file is not designed to be modified by the user, or used for synchronization purposes. Modifying it may cause unexpected behavior. For example, you may find that modifying some settings may not take effect.

We are indeed considering using a new manifest file in the scripts folder to synchronize settings in the future (maybe). In the latest beta version, we have added the import and export function of settings data.

So, for this issue, I will see how to solve it when refactoring the relevant parts. However, it is currently not recommended that you synchronize and modify this file. Synchronizing only the scripts folder is a good option for now.

[amonks]

That's really good context, thank you! #523 helped me understand why nativeChecks is useful.

For my use case, I'll just sync the scripts folder as you recommend — I'm totally happy with this outcome, so you're welcome to close the issue if it isn't useful for tracking.

You make a good point that checking the file for changes before writing it would be a better change than just sorting the file. I'm thinking here of lower-level observers like rsync or the filesystem itself, which may perform extra work if a file's inode changes. I think rsync, for example, uses inode timestamps by default (rather than file contents) to decide which files to skip, so just sorting the file wouldn't help there.

[ACTCD]

The current native checks and updates may be more frequent and cause issues such as #557. But this is probably the best option with the current logic and without a lot of refactoring.

To completely solve these problems requires a more comprehensive process design and refactoring. Let's keep this issue open so that we don't forget to consider this when doing related works.