I am unable to validate this change locally, and the best way I can think of is to merge it to alpha and try it from there.
My assumption is that clients would need to install @dhis2/ui, but I think that's ok (and that's what the majority of projects do anyhow) and it's better than having to dedupe or add a resolution every time there is an update to app-platform.
It's hard to test locally because right now, the shell is a dependency of cli-app-scripts and the UI library is a dependency of the shell. If I run a local version of init script, then it uses the published cli-app-scripts. I can change that manually to use a local version published from yalc, but then that still gets the shell from the published version. Having two levels of yalc dependencies (i.e. cli-app-scripts published through yalc, while using app-shell that's also published through yalc) doesn't quite work. If anyone has an idea of how this can be tested locally then let me know!
I am unable to validate this change locally, and the best way I can think of is to merge it to alpha and try it from there.
My assumption is that clients would need to install
@dhis2/ui, but I think that's ok (and that's what the majority of projects do anyhow) and it's better than having to dedupe or add a resolution every time there is an update to app-platform.It's hard to test locally because right now, the
shellis a dependency ofcli-app-scriptsand the UI library is a dependency of theshell. If I run a local version ofinitscript, then it uses the publishedcli-app-scripts. I can change that manually to use a local version published fromyalc, but then that still gets theshellfrom the published version. Having two levels ofyalcdependencies (i.e. cli-app-scripts published through yalc, while using app-shell that's also published through yalc) doesn't quite work. If anyone has an idea of how this can be tested locally then let me know!