Automatically add javascript SPAs

[Frosco]

What should we add or change to make your life better?

It would be really cool if Tye recognised javascript SPAs (e.g. React-frontends) that are part of the folder structure. Tye would include them when you use tye run and display them in the dashboard.

Currently I would either create a Dockerfile to generate an image and instruct Tye to use it or run "npm start" and "tye run" simultaneously while adding an ingress to tye.yaml and configure the frontend to use it. If I was a beginner I would have loved to have Tye do this for me.

Why is this important to you?

Lots of projects I hear about from colleagues use different .NET backend services together with a React/Angular/Vue frontend. These would be deployed on the same cluster as part of the microservice-project. Including SPAs to tye would take away further difficulty for newcomers.

[davidfowl]

Unless it was part of the .NET application itself or there was a convention that > 90% of people use for their front end apps that was pretty much de-factor, automatic discovery is a losing battle. It woudl be much easier to support calling npm start on a declared folder with package.json though.

[MrCrimp]

A temporary workaround could be a .csproj file in the web app directory with dotnet publish support, running npm run start/build in MSBUILD tasks, like those that Visual Studio SPA templates create? Gets the job done.

Eg. https://docs.microsoft.com/en-us/aspnet/core/client-side/spa-services?view=aspnetcore-3.1#publish-the-app

[tebeco]

It would be much easier to support calling npm start on a declared folder with package.json though.

That look like a "standard" for front developper

Personnal opinion: tye init and tye run could/should works for npm start without the existence / usage / having to rely on MsBuild as much as possible, the only exception is only when developper explicitly try to wrap SPA within an existing csproj project

Node/Npm:

• no equivalent of "solution"
• only "project" defined by the presence of package.json
• npm start is a native npm command
• working with front SPA is often NOT part of a csproj and also NOT part of an sln either

If a discovery can be made, then is it possible to have it done by relying on the OS FileSystem:

• Start at repo root level
• get all package.json
• make it a project enrty for tye

concider either:

• ignore those that are aside / under a csproj
• add a tye init --includeSpaInCsProj (with a better name)
• As tye init relies on MsBuild SDK, is there a property that we could rely on, when a package.json is found next to a csproj to check if that package.json is already part of the sln>csproj>Spa ?

[jkotalik]

Another thing we could consider is supporting the new js proj files: https://docs.microsoft.com/en-us/visualstudio/javascript/javascript-in-vs-2019?view=vs-2019.

However, I think it will be significantly more common to not have those files.

[tebeco]

Please concider that teams just do not open Visual Studio for SPA (they don't want to)

They higthly uses VsCode and just "Open Folder" That's why simply relying on the presence of the package.json should be concidered as a "first citizen"

Also it's probably possible to also look for vsproj or anything else. For example, as of today the tye init adds litereally everything that can starts, well that would just be "one more entry" :D

[onionhammer]

Unless it was part of the .NET application itself or there was a convention that > 90% of people use for their front end apps that was pretty much de-factor, automatic discovery is a losing battle. It woudl be much easier to support calling npm start on a declared folder with package.json though.

Being able to call 'npm start' or some NPM command as a tye service would be tremendous

[onionhammer]

Was this idea rejected or just removed from the backlog without discussion?