I've written 21 Blog posts about the new umbraco backoffice now!, I've written a dotnet template to help you get started and I not-so-secretly also have the uSync package pritty much working in the back office too 🎉.
So I though it probibly also a good time to document my dev setup for how i am working with the new backoffice.
This is obviously subject to change, I keep tweaking things, but at the moment this works quite well for me.
This is my Development setup, if you think i've missed anything please let me know!
1. The Early Adopter's Umbraco Template,
Quick plug, for the Early Adoper's template, its a quick install :
dotnet new install Umbraco.Community.Early.Templates
and then you can fire up a new project really quickly.
dotnet new early.umbracopackage -n MySuperPackage
This will set you up with a solution, with the projects in it to build your next great package.
2. Tasks.
Building both a front end and backend project means that there are a couple of diffrent things you have to do to keep everything upto date.
Dotnet builds
For DotNet. I often will build the site and then run it via visual studio, either via Debuging or the "view in browser" command (which runs the site but not in debug).
I do very occasionally use Hot Reload, but more often then not i forget about it, and just rebuild/restart the site to see changes.
Typescript / Vite
The early adopter templates, have a few scripts setup in the package.json file to make it quick to get going the one i am using the most is the watch command:
npm run watch
That will watch the folder for changes and run anything through vite should it change.
So i don't forget to run the command I am using the NPM TaskRunner extension for Visual Studio to spin up the watch command when i open the project.
A limitation of the Extension (well actually i think its of the task runner extension points in visual studio). Is it can only find tasks in the root of the project, and for me the front end code is actually buried several layers deep.
The soluition to that is to have a 'dummy' package.json in the root of the project with script commands that point to the actual commands you want in the sub folders (this is in the dotnet template)
{
"name": "MyPackage.1",
"private": "true",
"version": "0.0.0",
"type": "commonjs",
"description": "proxy package.json",
"scripts": {
"build": "cd ./MyPackage.1.Client/Assets/ && npm run build",
"watch": "cd ./MyPackage.1.Client/Assets/ && npm run watch"
}
}
- Reloading / Refreshing during development. With my project website up and watch script running, I have quite a nice streamlined development.
If you make changes in your typescript, then the watch command will mean that vite processes it and places the bundled javascript into the package project's wwwroot folder.
Because the package is a Razor Class Library (RCL) and our website project has a dependency on the package library, any changes in the wwwroot folder are reflected immidiatly in the website project.
In visual studio I have Hot Reload enabled (Options -> Debugging -> general).
This means Visual studio injects a bit of javascript into the site you are developing that it can then use to trigger a refresh of the page should anything change.
I find you also need the developer console of the browser open with the "Disable cache (While DevTools is open)" box ticked.
4. Development Environments
At the moment i am spending my time split between visual studio and visual studio code (maybe a sign i need to try Rider again?).
I find visual studio is still the best place for me to do .net development, and while it does do a good job with typescript and vite, i find Visual Studio code is slightly better at managing that side.
My preference for VSCode Mainy comes down to auto complete working inside the html elements of a lit file.
If i can work that out, I might switch back to just one environment.
For now i also have the Open in visual studio extension in Visual Studio so i can right click on a folder and quickly open it in VSCode.
Next - Deployment
I haven't quite gotten to package deployment yet, but its on my list, i know the Umbraco Package team have some nice github scripts for package deployment in their Package template so that might well be my starting point when i get there.
Top comments (2)
Hi Kevin, great series of posts.
Small obstacle that may confuse first-timers like me: due to the long name of the "14.0.0--preview005" package, you may get an error like this when trying to build in Visual Studio:
System.InvalidOperationException: The item metadata "%(FullPath)" cannot be applied to the path ...because it exceeds the maximum allowed length.If you experience this, a workaround is to customize the location of you global Nuget assemblies folder to a short path, i.e. "C:\Nuget" as explained here dev.to/tombohub/how-to-change-defa...
Thanks!
Yes, well spotted 👍One of those things you change and forget you've done
I think i have applied the registry hack , to turn off long file names.
learn.microsoft.com/en-us/windows/...
i think there is something in one of the Umbraco repos, about it, (wether it be shorten folder names in their packages or something i am not sure).