Discussion about the future of project syncing between `settings.json` and `vcc.litedb`

[anatawa12]

Hello, I'm a developer of several compatible vpm clients.

In the current VCC (v2.3.1), projects does not exist in the settings.json will be removed from vcc.litedb and projects do exist in settings.json are added to vcc.litedb.

According to this comment by orels1 and VCC 2.2.0 release note, this migration will be removed in the future version of VCC.

However, Current mechanism for syncing projects between settings.json and vcc.litedb will cause several problems when the sync is removed, so I want to discuss and suggest about this.

The problems

The current VCC and VPM CLI's mechanism for syncing projects between settings.json and vcc.litedb is like as follows:

1. If userProjects field in settings.json is null or field does not exist, it will be initialized as an empty array.
2. For each project in vcc.litedb, if the project does not exist in userProjects, it will be removed from vcc.litedb.
3. For each project in userProjects, if the project does not exist in vcc.litedb, it will be added to vcc.litedb.

However, this would cause problems when the sync is removed:

1. If the VCC remove the userProjects field of settings.json after migration deletion, all projects in vcc.litedb will be removed when an older version of VPM CLI or ALCOM is used.
2. Even if the VCC does not remove the userProjects field of settings.json and just stop updating them, some newly added projects in vcc.litedb will be removed and removed projects will be added again when an older version of VPM CLI or ALCOM is used.

In addition, the lack of information about after migration deletion makes it difficult to prepare for the future. For example, I can imagine a tool that adds projects to VCC (Tool A). For current VCC Compatibility, Tool A should add a project to both settings.json and vcc.litedb. On the other hand, if the migration is removed, Tool A might be better to add a project only to vcc.litedb. However, there is no way to know whether the migration is removed or not.

The solutions

To solve these problems, I suggest the following solutions:

• If userProjects field in settings.json is absent or null, it should be kept as it is and do not migrate projects. This should fix both problems 1 and 2 if the older version of VPM CLI, ALCOM and VCC follow this rule.
• Document that if userProject field is absent in settings.json, it should mean migration is removed so tools that manage project should only see vcc.litedb.

How do you think about this? I don't know how VRChat thinks of compatibility with older versions, but I want to keep the compatibility as much as possible so that users can use the tools they like. That's why I opened issue here.

[orels1]

Hey You pretty much described the plan we had. While there is no finalized path for it just yet, this was the general idea for when the switchover happens:

• Migrate projects from settings one final time
• Remove the user projects field from settings completely, as its no longer needed
• Launch an Open Beta with those changes, communicating that the previously announced deprecation time has arrived
• If all looks good - move it live

There is also a potential of introducing the version int in the settings file to make tracking such changes a little easier on the developer side.

If you have any concerns with that approach, I'd love to hear them.

[anatawa12]

I think final migration path is no problem and introducing version field might also be good it was introduced much before actual change.

However, I have concerns about the current behavior if VCC with settings.json without userProjects field as described before. It will erase all projects in vcc.litedb. This behavior will remove projects unexpectedly by using legacy vcc or vpm cli. As a countermeasure to this problem, I think VCC should detect absence of userProjects field and should not clear projects in vcc.litedb.

[orels1]

I see, I suppose that's reasonable. We generally see pretty high adoption of current versions, but in case of unexpected bugs its not uncommon for people to use older versions.

I think the best approach would be to roll this out in stages.

1. Stop deleting projects in the DB if they are missing in the settings list. Point people at the liteDB studio if they need to clean things up manually in case they are unable to use VCC for that for some reason.
   • Add a version: 1 to the settings file alongside this so that the VCC could alter the logic going forward
   • Setup a backup logic of the DB on VCC launch, e.g. vcc-backup.litedb
2. At some point down the line
   • Increment settings version to 2
   • Remove the userProjects key
   • DB is now the only source of truth on the projects list

This way we could instruct people who are using really outdated VCC/other tool versions that enforce parity between settings and litedb to update and "restore" their litedb from a backup

Just to note that this isn't the final plan by any means, more of a proposal