Our team has been forking and modifying the Rancher Dashboard repo so we are very interested in the outcome of its transformation to using a plugin model. This morning, I tried using the instructions at https://github.com/rancher/dashboard/blob/master/docs/developer/PLUGINS.md with the latest code in

master

only to get tons of unresolved modules when starting the new application with only the `shell`in it. It seems that the

shell

is referencing components that have been moved out of the

./shell

and into `./pkg/rancher-components`that it is unable to resolve. For example:

ERROR in ./node_modules/@rancher/shell/components/RelatedResources.vue?vue&type=script&lang=js& (./node_modules/cache-loader/dist/cjs.js??ref--6-0!./node_modules/thread-loader/dist/cjs.js??ref--6-1!./node_modules/babel-loader/lib??ref--6-2!./node_modules/vue-loader/lib??vue-loader-options!./node_modules/@rancher/shell/components/RelatedResources.vue?vue&type=script&lang=js&)
Module not found: Error: Can't resolve '@components/BadgeState' in '/Users/rpatrick/Projects/research/verrazzano-dashboard/node_modules/@rancher/shell/components'

Any idea how to get past these issues?

Can I confirm how you're running your app, via the root package with plugins in the pkg folder, or in a new app with shell and plugins as dependencies? We're concentrating with the former and the latter hasn't quite kept up with master

@stocky-account-63046 I am simply trying to follow the instructions to Develop a new UI

I would suggest pausing on any method that imports shell as a dependency. At this stage it's best to just concentrate on adding your changes to a new plugin by adding it as a directory in pkg (this will get automatically installed when you build the dashboard). It sounds like you've already forked the rep, so this shouldn't be much of a departure from your current flow. In terms of customising the app marketplace and installed app pages, we don't have a direct way to do it but you might be able to replace the route via your plugin and show your custom pages

@stocky-account-63046

In terms of customising the app marketplace and installed app pages, we don't have a direct way to do it but you might be able to replace the route via your plugin and show your custom pages

Originally, we were hacking the binary data in the ConfigMap that stores the information about which charts should be hidden but that felt like it might be brittle since it didn't appear to be intended for public consumption. What we ended up doing was to simply create a JSON file with a list of plugins we wanted to hide and then inject a little code

catalog.js

file's `filterAndArrangeCharts`` function to return

false

if the chart was on our list. Maybe you could consider adding the ability for a plugin to supply a list of hidden charts that the main flow processes when deciding what to display?

Sorry for the delay, it looks like you should be able to hide charts already by adding the

<http://catalog.cattle.io/hidden|catalog.cattle.io/hidden>

:`true` annotation. For your use case is this possible, are the charts managed by you?

@stocky-account-63046 these are charts that come built-in with Rancher that we need to hide.

I don't think the charts are CRDs. I'm a FE guy and we call

/v1/catalog.cattle.io.clusterrepos/rancher-charts

which i think calculates charts on request. If you're curious about clusterrepo resources you can prod around them using

/v1/catalog.cattle.io.clusterrepos

yeah, that's what we saw and we injected our code to process on the response of that call. I am not sure how to "annotate the charts" since we don't technically own them... 😉

a terribly manual way might be to fork the repos and replace the default rancher one's with them. you'd obviously then need to rebase that fork when required

yeah, don't think we want to do that. Our current solution requires forking the repo and injecting a snippet of code into your code path but it is not that bad. Where I would like to get to is to be able to do everything we need via some public mechanism so that we can eventually get out of the business of forking your repo...

With the plugin mechanism you would still need to maintain some code and apply the plugin at setup/runtime via a soon to be released process. On the plus side that would remove the fork. Think it's best though to create an issue with the problem and we can come up with a fix other recommendation

Thanks!