The workflow you are describing and the problems that it creates is why are thinking about the possible solutions and trying out the options.
We always - ALWAYS had two git repos. One for frontend with mostly html/js/css with just enough php or nodejs to mount it locally and load includes and so on.
The sencond git repo was the backend with the front-end integrated at a specific point in time.
How to communicate the changes in front to backend was our problem. Doing it manually requires a lot of communication and it's very fragile process, and doesn't matters if it's the back or frontend team who makes that integration.
We tried the solution I'm exposing here, that is publishing the front-end to a package manager (we choose private npm, but it can be private nugget). This requires automation, but it works well. But it's not a solution to the communication problem. We had several issues in which a feature modification involved both front and backend functional changes, very much interdependent, which lead to a complex version planning. That was a pain.
BUT, Now we are discovering that the front and the backend should be very different or be the same. Having this ficticious separation is the real problem here. It's an architecture thing. If you can publish to production one appart from the other, they should be different version and diferent repos. If not, then it's just one repo and one version to work on. Separating them causes innecesary pain.
So, we habe two types of projects now on. We have a complete SPA/PWA as frontend with a backend as JSON-API or we have only one project with front-end and back-end working in the same repo.
In the case of SPA/PWA app, the front-end and the back-end teams are separate and work with separate versioning, both deploying to production at it's own pace.
In the case of a traditional backend-rendered app, the team has both front-end and back-end devs working on the same issues/features at the same time on the same repo with the same tools.
Specifically with dotnet apps, all devs work with visual studio and windows. Windows and visual studio proficiency should be required for front-ends to work on dot-net projects. It's actually not that hard.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
The workflow you are describing and the problems that it creates is why are thinking about the possible solutions and trying out the options.
We always - ALWAYS had two git repos. One for frontend with mostly html/js/css with just enough php or nodejs to mount it locally and load includes and so on.
The sencond git repo was the backend with the front-end integrated at a specific point in time.
How to communicate the changes in front to backend was our problem. Doing it manually requires a lot of communication and it's very fragile process, and doesn't matters if it's the back or frontend team who makes that integration.
We tried the solution I'm exposing here, that is publishing the front-end to a package manager (we choose private npm, but it can be private nugget). This requires automation, but it works well. But it's not a solution to the communication problem. We had several issues in which a feature modification involved both front and backend functional changes, very much interdependent, which lead to a complex version planning. That was a pain.
BUT, Now we are discovering that the front and the backend should be very different or be the same. Having this ficticious separation is the real problem here. It's an architecture thing. If you can publish to production one appart from the other, they should be different version and diferent repos. If not, then it's just one repo and one version to work on. Separating them causes innecesary pain.
So, we habe two types of projects now on. We have a complete SPA/PWA as frontend with a backend as JSON-API or we have only one project with front-end and back-end working in the same repo.
In the case of SPA/PWA app, the front-end and the back-end teams are separate and work with separate versioning, both deploying to production at it's own pace.
In the case of a traditional backend-rendered app, the team has both front-end and back-end devs working on the same issues/features at the same time on the same repo with the same tools.
Specifically with dotnet apps, all devs work with visual studio and windows. Windows and visual studio proficiency should be required for front-ends to work on dot-net projects. It's actually not that hard.