There are probably many reasons not to allow this, but I’m wondering if there is any safe way to store custom json data in the project settings using the editor api?
My use case for this is it would be really helpful if our Package Manager chrome extension could store and access data such as package names plus configuration info on a per project basis. Currently we are storing this data in a standalone json file in the asset registry, but we need to add additional logic to track the file (renaming/path change etc) and there’s a few edge cases where it breaks down.
Ideally we could have a slot in the project settings to store this data which would then sync with everyone on the team. The data we’d want to store would be something along the following lines:
Allow an dedicated field where arbitrary json data can be stored?
Probably safer; add a field to the project settings that points to an asset ID. Similar to the Area light LUTS etc. This would mean we can keep the config file in the asset registry, the user manually selects it, and it doesn’t pollute the project settings with arbitrary data.
Hey! Interesting use-case you have there, and I can definitely see how this can be useful. My first impression on this is that indeed option #2 is safer, and if we were to implement option #1 we would need to add constraints (such as in total size limit in bytes, limit supported types, etc).
While we discuss internally what can be done about this, can you elaborate a bit more on the “edge cases that break down” your current approach of using a JSON file in the Asset Registry? Perhaps we might find a way of improving that workflow without needing to mess with Project Settings.
For sure. As a quick overview; the extension has a UI Panel that operates on a json file within the registry. It displays information stored in the file and and allows users to update it by adding and removing packages.
The above image is showing data stored in the json file
As we don’t have a fixed reference to the file ahead of time we have to search for it using the following assumptions when the editor loads or when a new file is created
1. File must be a json file 2. File must be in the root of the registry 3. File must be named 'package.json’
Any file that meets these requirements is valid and we assume we can store and retrieve data from it. If no file is found we disable the extension which gives developers the abilty to opt-in/out
However this test isn’t totally reliable as assets can actually share names, for example you can have multiple ‘package.json’ files in the root which would all pass the above test. A more reliable identifier would be the asset ID which is unique across the registry.
An example where this might cause issues is where two or more developers working on the same project where they both individually create a package.json and add packages to it, potentially making two files that need to be merged.
Upon reading your comment, my honest first reaction is that using these file name and path constraints is quite sufficient, and actually perhaps not as bad as you’re picturing. It seems to me to be an already familiar enough flow from NodeJS (and other) development workflows.
Additionally, the example you mentioned about 2 developers making changes to the package.json would also need to be resolved in some way if there are differences during merge between branches. Currently, we don’t have a way of displaying an UI for such a complex use-case, so the conflict resolution would need to be manual too.
You could also look into using Asset Tags to help specify your plugin’s files from others. Also, to be clear, having those 3 constraints (must be json, must be in root, must be named exactly ‘package.json’) is all already doable, correct?
I think the main concern is multiple files can be named package.json in the root and be a json file. I can add additional constraints such as asset tags, but they don’t really guarantee uniqueness without the asset ID.
Of course this is not an issue that needs to be fixed in the editor per se, but it would fix my particular use case.
I initially thought I could store a reference in the extensions chrome.storage, which would effectively solve my issue, but this of course is scoped to the user and wouldn’t work with projects with teams.
