Could not resolve dependency: npm error peer @types/react@“>=16.8.0 <19.0.0” from @fluentui-contrib/react-virtualizer@0.1.0 npm error node_modules/@fluentui-contrib/react-virtualizer npm error @fluentui-contrib/react-virtualizer@“0.1.0” from the root project
In your case, npm i --force is needed because your package.json has versions requirements that conflict. Specifically, for the error you are seeing above, it is because your package.json has "@fluentui-contrib/react-virtualizer": "0.1.0", (indicating this exact version of this package is needed) and at the same time has "@babylonjs/inspector": "8.33.3-preview", which has its own peer dependency that is "@fluentui-contrib/react-virtualizer": "^0.5.3",. These two versioned dependencies on @fluentui-contrib/react-virtualizer are incompatible.
I’m guessing you have these explicit dependencies because you used the Inspector v2 samples as a starting point? Unfortunately those dependencies are explicitly listed in the samples because I couldn’t get codesandbox to work without them being explicit for some reason. I’ll need to investigate more so we don’t cause confusion on this.
In any case, the solution for your app would be to remove all the extra dependencies in the package.json and let npm resolve the peer dependency graph and package versions for you. E.g.
That is true The confusion came from Codesandbox example.
After removing extra dependencies finally everything works fine.
And now I have another question:
Could it be possible to add some HTML to the ExtensionFeed description, for example the link to the source code of the extension?
We can definitely improve extension description support. Having just a string was a quick way to get started, but I definitely agree this is very limited. Some possibilities:
Just allow for more well known properties. Right now the extension metadata is actually based off of package.json (because of the idea that one possible future direction for extensions would be to pull them from npm package feeds), so the simplest thing to do would be to just add and respect more package.json fields, like repository. This would probably be my vote right now.
Allow for arbitrary html. This could work, but we’d have to sanitize it, and make sure it works ok in terms of default theming being applied.
Allow for arbitrary markdown. This could be nice, but would require taking on a markdown library dependency, which would be the challenge.
If you think option 1 would work for your needs for now and have any interest in implementing it we’d be happy for the contribution. If not I could probably make the change later this week!
Option 1 seems to be logical, but there are other nice fields besides repository like version, homepage, license, and people fields: author, contributors
Option 2 (arbitrary html) also nice to have but probably we may create a Feature request to see the demand for it.
The big problem is where to find the installed extension after a teaching popup was closed. Probably there could be another button near “UnInstall” button, for example “Show” button which would call teachingMoment.
Also, would be great to have different colors for “Install” and “Uninstall” buttons.
I am still getting used to the Inspector v2 code, so better you make this change
If you’ve updated the version of the inspector package, it’s possible the local storage got in a bad state because of evolving code/patterns around extension management during our preview stage. If that’s the case, you could try clearing local storage. If it still repros, I can clone your repo and try to repro probably early next week. If it’s a bug we’ll definitely want to get to the bottom of it!
After clearing the local storage the error now appears not after loading the Inspector, but after the first attempt to install the extension. If I close the error popup and click Install again, everything works as expected.
This may not be a bug, but the order of the displayed items seems to be different from before. Previously, they appeared to be sorted, but in v2 they no longer seem to be sorted. Is this the intended behavior?
It is kind of the intended behavior currently because getting the label is a little heavier so we can react immediately to changes (like the name property changing) and because of the virtualization we do to make scene explorer work with very large scenes. It’s definitely possible to have it sorted if folks find this valuable though!
At least alphabetical sorting for identical nodes would be great (like in the old Inspector). Probably is possible also to add more settings for node sorting to make the using of the Inspector v2 even more convenient.
In this case the problem is that you are adding the service definition both statically (passed in with the serviceDefinitions property of the options) and also it is included in the list of service definitions for the dynamically installed extension, so it is double registering the same service. I sent a PR to show the change.
To make it easier to avoid such a problem, I think there are a couple things we could maybe do:
If the unique identity of the service conflicts with an existing one, and the service definition is actually the same object, the error could just tell you it is the same service being double registered (as opposed to two different services using the same identity). This probably would have given you more clues as to what was wrong.
It might help to converge the serviceDefinitions and the extensionFeeds options, such that there is only the concept of “extensions” but you could have some of them be pre-installed and optionally not uninstallable. Maybe collapsing these into one concept would make it easier to understand (though maybe more verbose in code), I’m not sure.
Happy to hear any other ideas that would help improve clarity or make issues easier to diagnose!
Thank you very much!
Now everything works as expected.
I think I’ll simplify my testing repo to the bare minimum to avoid such issues
Option 2 seems to be less prone to user errors
Will be there a way (or it already exists) for an extension to be pre-installed with possibility to uninstall?
Is it possible to add the ability to import GLB files (not just animations) into the scene via the Import extension? I believe this feature is in high demand.
I have a PR that adds all this extension metadata and improves the extensions dialog by exposing all the new metadata, changing the color of the Install/Uninstall buttons and changing their text to Get/Remove and adding icons, adding a green check for installed extensions, and some overall UX improvements in the extensions dialog.
I thought about this some, and it will be a bit more involved to get predictable sorting behavior when entities are renamed or added, so I’ve added this to the list of feature requests in the GitHub issue.
I think this will be part of a broader effort for Inspector v2 around how we handle asset creation flows holistically. We are planning to tackle this after finishing parity, but be assured it is on our radar!
That is what I have in my test project that I created from scratch with the commands from my previous post.
The confusion came from Codesandbox example.
