chore,docs: update package.json and docs to support OpenUPM

[yuna0x0]

Add OpenUPM support for DressingTools.

---

OpenUPM is a package registry for open-source Unity packages. It can handle package updates and dependencies properly compared to UPM Git URL.

Personally, I recommended to use OpenUPM for installation if user is not using VCC. Especially for users who are not using DressingTools for VRChat.

Users can benefit from automatic package updates and dependencies resolving that OpenUPM (Unity scoped registry) provides.

---

In order to support OpenUPM, DressingTools' dependencies AvatarLib and DressingFramework have been added to dependencies property in package.json.

Hence, in the future user will have to install AvatarLib and DressingFramework first, then DressingTools. Otherwise, Unity will refuse to install DressingTools because its dependencies are not fulfilled.

---

Both English and Chinese (Traditional) documentations are updated.
For other languages, because I am not fluent in those languages, I am unable to help with those documentation.

---

OpenUPM page for DressingTools and its dependencies:

DressingTools:
https://openupm.com/packages/com.chocopoi.vrc.dressingtools/

DressingFramework:
https://openupm.com/packages/com.chocopoi.vrc.dressingframework/

AvatarLib:
https://openupm.com/packages/com.chocopoi.vrc.avatarlib/

[poi-vrc]

Thank you for the pull request. I have considered about OpenUPM support before when VCC hasn't come out yet.

But since VCC uses an alternative approach other than using the Unity scoped registry approach. I am concerned about both Unity will try to obtain UPM packages listed in dependencies from the scoped registries, while VCC downloads zip packages listed in vpmDependencies into the Packages folder.

Would this cause a conflict or confuse Unity to search the packages from scoped registries while OpenUPM scope is not installed? I think Unity prioritizes project embedded packages placed inside the Packages more than the one downloaded by UPM though.

[yuna0x0]

After doing some in depth testing.

No, this won't cause a conflict or confuse Unity while OpenUPM scope is not installed.
Unity will list out the dependencies as custom packages.

---

If user have the package installed via VCC while OpenUPM scope is installed. Unity still prioritizes Custom packages placed in the Packages folder.

However, users might be confused by package manager as it will display it's coming from a scoped registry while it's actually using a custom one placed in the Packages folder.

Therefore, it's worth adding a recommendation for user to add the package using only one of the documented method, better not mix and match.
User can still install other OpenUPM or any scoped registry packages, just better not install our packages by using both VCC and OpenUPM at the same time.

[poi-vrc]

Thanks for your further testing. I think there might have a few more things to address before we can merge this PR.

• dependencies using the same constraints listed in vpmDependencies
• Japanese documentation
  • I will help you to finish this after fixing the other languages' docs
• Do we have to remove the UPM Git URL, ZIP options from the docs for clarity?
• Library/PackageCache/xxx.xxx.xxx and Packages/xxx.xxx.xxx compatibility
  • I think UPM install to the library packagecache instead. I am not sure about the compatibility if I am trying to access a Packages/xxx.xxx.xxx/somefile.txt in code, will it read the correct file from Library/PackageCache/xxx.xxx.xxx/somefile.txt (I think the concern exists with UPM Git URL though)

[poi-vrc]

Since the project follows conventional commit, please change the commit message to
chore,docs: update package.json and docs to support OpenUPM

[poi-vrc]

I think we could try including this OpenUPM support into 2.6.0-beta.1 (the version coming this week). And allows you to test installing this pre-release version.

P.S. Now master is 2.7.0-beta.1, branch 2.6.x is 2.6.0-beta.1. I will cherry-pick this commit to 2.6.x later on.

[yuna0x0]

Do we have to remove the UPM Git URL, ZIP options from the docs for clarity?

I don't think we should remove the UPM Git URL and ZIP options from the docs entirely. As there might be users that still need the option to install it via Git URL or ZIP files (Eg, offline network environment, or corporate network limitation).

For clarity, I recommend we can hide those options inside things like HTML <details> (or similar shortcode in your SSG) named Advanced or something.

Library/PackageCache/xxx.xxx.xxx and Packages/xxx.xxx.xxx compatibility

I am also not sure about the compatibility if we are trying to access a Packages/xxx.xxx.xxx/somefile.txt in code. I'll have to test it out.

[yuna0x0]

After testing, Unity will read files correctly from Library/PackageCache/xxx.xxx.xxx/somefile.txt when using path Packages/xxx.xxx.xxx/somefile.txt.

---

For instance, I have self-hosted a local private scoped registry using Verdaccio (My setup files).

Adding the following example code to UpdateChecker.cs:

private const string PackageJsonPath = "Packages/com.chocopoi.vrc.dressingtools/package.json";

private static ParsedVersion GetLocalPackageJsonVersion()
{
    try
    {
        var reader = new StreamReader(PackageJsonPath);
        var str = reader.ReadToEnd();
        reader.Close();

        var packageJson = JObject.Parse(str);
+       Debug.Log("[DressingTools] package.json: " + packageJson);
        ...
    }
    ...
}

Published the modified package to the registry and added the package to Unity. The result is shown in the screenshot below:

---

Packages that use a scoped registry will be imported into Unity's Asset Database just like custom packages. The only difference is that its entire package folder will be immutable. Therefore, your code can only read but not modify the content in the package.

Also, due to its immutability, any files in the package that are missing their corresponding Unity .meta files will also not be generated by Unity. Hence, Unity will keep throwing errors and refuse to import those files.

We should generate those missing .meta files (if any are missing) before this PR is merged.
From my observation, both com.chocopoi.vrc.avatarlib and com.chocopoi.vrc.dressingframework have files that are missing required .meta files.

[poi-vrc]

I will fix the missing meta files by promoting a new patch version for each two packages.