https://discord.umbraco.com logo
Join Discord
Powered by
Merge of repos
# contributing
j
Has anyone had a chance to work with the contrib branch after the backoffice files have been merged in? Have you had any trouble with it so far?
w
Nope not had a chance yet
c
Not yet, but I'm looking forward to doing so soon.
j
Well, I can't pull from contrib.
But that's to be expected.
I guess.
If I remove 
Umbraco.Web.UI.Client
I can pull again.
c
I'm going to happily delete my v14 folder and start again
l
I was on the v15/dev branch, not the contrib, but figure would be the same process... I had to delete the 
Umbraco.Web.UI.Client
folder, as Jason said, to be able to pull. Then was getting build errors. Fixed by manually running 
npm ci
and 
npm run build
. Or perhaps restarting Rider, not entirely sure TBH but I got there!
j
Great, @Lotte and @Jason. I suspected you had to delete that folder before being able to pull, as Git still sees the submodule until it can pull the updated 
.gitmodules
file which removes the submodule: https://discord.com/channels/869656431308189746/882985025803530332/1304774877366059091
@Lotte > Yes, the autodetection for rebuilding the backoffice is not the greatest. I have started a PR to fix that: https://github.com/umbraco/Umbraco-CMS/pull/17527
c
@Jacob Overgaard , I'm almost there but getting this error now
I installed npm 20.18.0 and vite but still not working
j
This is because some of the NPM scripts try and set environment variables inline, which doesn't work on Windows (!) You need to use 
npm run dev
and modify any necessary environment variables in your own .env.local file (copied from the main .env file).
c
ok, that seems to have worked.
but not quite. I have an empty site now
j
N.B. you only need to do that if you're wanting to do "live" backoffice work against the server but using backoffice code served from Vite. There are some hoops to jump through to get that set up.
c
j
Well, nothing has really changed in that regard. If you want to do Backoffice development with live reload and such, that is the guide to follow. Otherwise, a normal build should just work more or less (you might need to force a rebuild of the backoffice client files if you already built it once)
j
TBF those pages do set out slightly conflicting instructions as they're talking about different workflows. Run a build of each as per the main contributing guide first. Usual rules for debugging then apply, turn off or empty browser cache, burn cookies/local storage etc.
c
Ok I am rebuilding the backoffice and will get that running again and then will run the vite one
j
Yeah, you are right, @Jason. For a normal build, [this PR](https://github.com/umbraco/Umbraco-CMS/pull/17527) has just been merged, and once it hits the contrib branch, it will automatically rebuild the backoffice when needed which should eliminate any quirks you might experience on a standard workflow.
@CodeSharePaul > If you see a blank screen on the Vite server, it most likely means that the server refused your authorization request. You can check that in the console of the browser. If that is the case, it means something is up with the appsettings: Is the BackOfficeHost set? And on the Vite side, the 
VITE_UMBRACO_API_URL
needs to be pointing to your Umbraco instance url.
To test it out, you can also run 
npm run dev:mock
to mock all the API requests, which lets you quickly get to do UI development
j
(not on Powershell on Windows you can't)
j
True, if someone could introduce crossenv that would be 😘
But set 
VITE_UMBRACO_USE_MSW=on
in 
.env.local
and it will mock the responses as well
I'm pretty sure [cross-env](https://www.npmjs.com/package/cross-env) would solve it
Alternatively, Bash on Windows (GitBash and Linux Subsystem for Windows) can use native *NIX environment variables as well
c
I was just following the documentation. It feels like there are lots of undocumented bits of assumed knowledge
j
Do you have the correct app settings in place?
Copy code
"Umbraco": {
    "CMS": {
        "Security":{
            "BackOfficeHost": "http://localhost:5173",
            "AuthorizeCallbackPathName": "/oauth_complete",
            "AuthorizeCallbackLogoutPathName": "/logout",
            "AuthorizeCallbackErrorPathName": "/error",
        },
    },
}
I don't think it's so much about assumed knowledge, but that there's a lot of ducks to get in a row for this kind of development flow to work nicely. Under the hood what's going on is massively complicated and though a lot has been done to hide that complexity away, getting set up is not the friendliest experience.
c
I do have the correct app settings in place. thanks for checking that with me.
This is my .env.local file contents
Copy code
ps1
# Copy this to .env.local and change what you want to test.
VITE_UMBRACO_USE_MSW=off # on = turns on MSW, off = disables all mock handlers
VITE_UMBRACO_API_URL=https://localhost:44339
VITE_UMBRACO_INSTALL_STATUS=running # running or must-install or must-upgrade
VITE_MSW_QUIET=off # on = turns off MSW console logs, off = turns on MSW console logs
VITE_UMBRACO_EXTENSION_MOCKS=off # on = turns on extension mocks, off = turns off extension mocks
j
As an aside, it's worth pointing out that this setup is really geared up towards truly full-stack development with Umbraco. The server side APIs and backoffice can be developed entirely separately, and for some people that's going to provide a better development experience over all.
c
I just want to be able to work with Umbraco how I have done in the past. I would to be able to edit the UI and the c# stuff
j
@CodeSharePaul Your setup seems correct to me. The error from your screenshot indicates that it did not recognize the sender URL of the authorization request, i.e. the BackOfficeHost did not match that of the Vite server. The value and URL must be identical down to the protocol and port. Vite checks for existing servers and chooses another port if it encounters a blocked port. Forgive me for eliminating the basics, but I assume your Vite server is running on http://localhost:5173 (no SSL) and you did not accidentally launch two Vite instances? Does it work if you access the backoffice directly on the server url? https://localhost:44339/umbraco ?
c
I will do a restart of my machine to try it again
j
...and dare I say, this is far beyond merging the repositories as you seem to be able to run Vite with the backoffice, so that is all well and good!
c
I have it working now. I restarted my machine, did a clean solution, rebuild solution. Then dotnet run in umbraco.web.ui, then npm run dev in umbraco.web.ui.client
Thank you for your help. For anyone else reading this, I may have caused this issue by not having the right version of npm installed at the start when I did the first build. That's the only thing I can think of
j
Or maybe you ran into some cross environmental quirks, where it did not act correctly with the hostnames. Glad you were able to resolve it!
c
I don't need to do anything with it yet, but I'm pleased I can get it running if I wanted to do any PRs
j
As an aside @Jacob Overgaard let's say someone's PR'ing a full stack feature - should we expect any changes to APIs to be reflected in the MSW?
I get your meaning but, technically speaking, neither of these approaches are analogous to how development was done with the old backoffice.... (hooray!) When I say "truly" full stack in this context I mean literally working on the C# and JS at the same time and needing to dip in and out of either. If you're the kind of dev that builds API first and then UI or UI first and then the API there's technically no actual need to ever run the backoffice in dev mode while targeting a live Umbraco instance. At the last hackathon contributions were made without running a live backoffice at all, or only using Vite builds instead of running it in dev mode. My point is, yes there's some hoops to jump through with this, but of the ways to work with Umbraco's source this is the technically most complex and also the route that I wouldn't expect everyone to want or need to use for the vast majority of PRs.
c
Thanks for the detailed reply. When I contribute to the code I like to have a familiar scenario like a starter kit installed so I can see “real” data. I get that it is good to separate front and backend but it’s also nice to know that it can be done for both at the same time.
j
@Jason In an ideal world, yes, the MSW handlers should be in-sync. The MSW handlers use some data stores behind the scenes to serve the mock data. These handlers rely on the real generated models of the API, so any changes to models will automatically be reflected. New endpoints, however, will not automatically be added to MSW and we run into these from time to time. It usually does not take long to add it, so we have not set any automated checks in place in this area to verify mocked endpoints.
w
I just did a fresh checkout - as I was lazy and had no in progress stuff However as there is sooooo many npm run scripts I can never remember the correct combination in order to run locally without an Umbraco backoffice
Done
Copy code
bash
npm install
npm run build:for:static
npm run dev
Currently I get this error with the Mock Service Worker failing to boot up, seems to complain about mime type?! Any thoughts anyone, or do I need to run some more combinations of npm run scripts?! Is this documented anywhere in the repo for people wanting to contrib ?! https://cdn.discordapp.com/attachments/1307993168842719294/1309540276330696745/image.png?ex=6741f3eb&is=6740a26b&hm=8a063d736ad3969327367a0a90a0572109c49d889a8a7c71846810f7119e8fd9&
@Jason or @Jacob Overgaard any ideas what I am missing or done wrong ?!
j
Ha, yeah, looks like you've found an endpoint that isn't properly mocked.
Copy code
GET http://localhost:5173/umbraco/management/api/v1/server/status net::ERR_ABORTED 404 (Not Found)
I can replicate.
> I can never remember the correct combination in order to run locally without an Umbraco backoffice Normally you'd only need to run 
npm i
and then 
npm run dev
w
OK cheers Jason
So a bug at the latest commit in contrib branch ?
3d3b5d53d686d387682f8dc503e3d5d14c65a566
j
You need to manually install msw sometimes. I am not sure why it fails. But if you run 
npx msw init public
in the Client folder, it should work, @Warren Buckley
We have recently committed the file to avoid this. I think the problem started when it got removed at some point.
Also just merged v15/dev into contrib again, so it could have been recreated now if you pull down the latest
w
OK will try it now 🙂
Can confirm its alot happier now & doing 
npm run dev
works all a-okay now with the mocked data from the service worker intercepting requests
Quite a few 404's where I assume missing mocked data to return, but generally have something to look at and work with
9 Views
PreviousNext
Powered by