[MUSIC]
>> Hello everyone. My name is Gabrielle Crevecoeur,
and I'm the JavaScript and TypeScript
Tool PM here at Microsoft.
Today, I'll be presenting to you
the New JavaScript and TypeScript Experience
that we are trying to bring to you in Visual Studio.
To get started, we're going to talk about why
Visual Studio needs a new JavaScript experience.
From there, we're going to talk
about the features that we plan on
bringing with this new experience.
Show two demos.
One that caters to creating
this new JavaScript experience overall,
and then how to actually link up
this new JavaScript experience with a .NET Core project.
Then from there, we're going to talk about
some additional tooling that's available
to enhance this experience,
as well as what's to come.
Why we need a new JavaScript experience in Visual Studio?
Well, we've heard you all, we've heard the complaints,
and we understand that there is
a lack of support for frontend frameworks,
a lack of support for JavaScript testing,
as well as no way to properly manage your node packages.
There's this constant struggle
between switching between VS Code and
Visual Studio to do
frontend development versus backend development.
We've heard a lot of people just want to stay in one.
So we figured, why not try to improve our experience?
Some planned futures we want to bring you
is, first, CLI based templates.
Currently, right now, Visual Studio does
support Angular, React, and Vue.
A big complaint we got there is that our template
seem to be out of date and not
constantly updated as these frontend frameworks
tend to update themselves.
We figured why should we build
it when they've already built it for you.
Instead, we decided to bring
new projects and new templates that are built
from the CLI version you
have installed on your computer currently.
Visual Studio will no longer
be manually making them for you,
but instead, using the tools already on
your computer to create a new project.
Next, we want to make sure we're able to bring
JavaScript unit testing to the Test Explorer.
So we have brought in support for
Jasmine, Jest, Mocha, and Tape.
Then we understand that there is a lot of support around
NuGet and the NuGet package manager within Visual Studio.
However, how is that helping our JavaScript community?
We decided to bring in a console that'll help you search,
import, and manage your node module packages
in your JavaScript projects.
Lastly, we did hear a lot about
users switching between VS and VS Code,
and how sometimes that can be a little hard to get
a project started in one and debug in the other.
We decided to actually bring in
a feature that's very similar to that in VS Code,
which is a launch.json.
It'll be preconfigured for you,
and it'll allow you to debug and run your projects
between both editors seamlessly.
Enough of talking about it,
why don't I just show you how all of this works?
Let's just start with creating
a new JavaScript project in Visual Studio.
First, we're going to actually create
a new project as normal and define these templates.
We're actually going to filter by
TypeScript or JavaScript,
either one will work.
We're going to scroll to the bottom and you'll see your
New Angular, New React and New Vue templates.
We're simply going to select New Angular today,
give it a name as normal.
Once you press "Create", you're going
to see this command prompt.
This will happen for all three of
the frameworks that we currently support.
This command prompt is just simply showing
that these are actually being built from the CLI.
It needs the command prompt to actually run.
Now that the project is up and running,
let's start maybe by building it.
The build is going to take a while because we're
actually going to run an npm install,
which can take a bit of time.
So while it's doing that,
let's explore some things that might be a little bit
different as we're going through this new project type.
First, let's open up the project file.
First, at the bottom we have a different type
of target that is used to check if node is
installed for users and to make sure that
npm install does occur when a project is built.
Next, if you look at the property group,
a little bit above that,
you'll notice that we are actually bringing in
what JavaScript test framework
will be used for this project.
Because it is Angular,
it will be Jasmine.
But if you decide to use
something else, like Jest or Mocha,
once you add them to your project,
they'll be automatically added to your project file.
Next, you can also see above that your startup command,
which in this case is npm start.
That is actually coming from the
package.json that is created within this project.
If we keep going and we open up the "Properties",
you can then see that nothing is really needed
in your build command as we mentioned before.
All that's happening during your build is an npm install.
To deploy your project,
we already stated that your startup command
will be npm start,
but you can edit it to match
any other valid node command line prompts,
or you can simply edit
what the npm start command in your package.json.
Next, when we look at the debugging,
we need to make sure that the debugger that we want to
launch is based off of your launch.json.
That is actually important because I mentioned we're
now going to the system where you can run
and debug your projects in both VS and VS Code easily.
launch.json will be preconfigured
so you won't have to make any changes
for you out of the box.
But if you do want to go in there and edit it, feel free.
If we take a look at our package.json,
we'll notice that it's actually very
similar to a package.json you've noticed.
It is the default package.json from creating
your Angular application if you're just doing ng new.
When we do npm start in the deploy command,
it is simply running the npm start on line 6,
which will just do a simple ng serve.
If we open up our launch.json,
you notice that we only have two default configurations,
which are just simply to launch in
Chrome or launch in Edge.
It'll launch at a localhost:4200,
but feel free to change that if you would
like to do a different port.
Now our build should be complete and we're
actually going to run the project.
We're simply going to choose what we'd like
our browser to be and then launch.
At the bottom, you can see that npm start is actually
running and you do see an ng serve beginning.
Just like that you have Angular app up and running.
The cool thing about it is we do have live reloading.
I'm just going to simply go in and change a quick file.
Let's maybe try main.ts and add an alert.
Once we add this alert and we
actually save it and reload the project,
you'll then see the alert pop up.
This is all done without having to stop
the project and rebuild it.
Now, I'm going to try to debug it.
Add a small little break point and see how that works.
Once the project is reloaded, you see that up.
There's been a small stop.
We're going to hit "Continue".
Our debugging is letting us continue.
By hitting the "Continue" button,
we are now done debugging our one line of code.
Next, let's move into something a little different.
We mentioned the Test Explorer.
It's actually really big deal.
Let's move over now to an actual test file.
Within Angular applications, you'll always have your
app.component.spec.ts when you're doing an ng new.
We're simply going to have these three tests on
line 13, 19, and 25 run in the Test Explorer.
Let's do "Test", "Test Explorer".
You see once we open up our "Tests" and
it's doing test discovery,
it's going to do another small compilation of
the Angular project just as if Jasmine was running.
Perfect. Now we're done processing and you'll
see the test pop up in the Test Explorer.
All three have been discovered.
If we open it up, you'll see that
the titles all do match.
should render title is the same as
should render title in the spec.ts file.
Now, if we run all three of them,
we haven't made any changes
so everything really should be
building just fine and testing just fine.
Let's see what happens.
Perfect. All of our tests have passed.
That is how you can use the Test Explorer now
with JavaScript unit testing.
Now, let's go into the next demo of
actually creating a .NET Core and Angular Project,
but using the new JavaScript project type.
There's been a lot of work around .NET Core and how to
actually be working with a frontend.
There's been some new proxy work.
There'll be a little bit more additional files
in which you're used to seeing from previous versions.
First, we're going to start and create
a new project as usual.
From there, we're going to look up Angular.
I'm actually going to start with the
.NET Core with Angular project.
Give it a name, hit "Next",
just as usual, nothing crazy.
Now that the project is opened,
we see that this is very
similar to what we're used to seeing.
We have our .NET Core application
with a client app folder inside of it.
Well, we're going to change this up just a little bit.
The first thing you want to do
before you make any major changes though,
is you do want to restore your NuGet packages.
Perfect. Now that that's done,
we can now start to make some major changes.
Next, we're going to right-click on the ''Solution''
and do "Add", "New Project".
Then we're going to type in Angular again,
and we're going to bring in that new Angular template,
give it a name, and hit "Create".
Once again, when we still see the
same command prompt, it let us know that
the CLI is actually working
in building the template from scratch.
Now we have this Angular project
and we have this .NET Core project.
The first thing that we're actually going to do to make
this a little bit easier is
actually take all of
the contents out of the client app and
move it to the frontend application,
and simply just hit "Yes",
as we're going to replace everything.
Currently, these two templates are one-to-one.
Only thing that's been additionally added is
the proxy work that we've mentioned before.
Now, our source files would be the same as far as having
the same frontend
for the weather forecasts and things like that,
and now we can actually delete
the client app folder out of the .NET Core project.
We no longer need that.
But now we do have to make some changes.
The first thing we want to actually
edit is that launch.json.
By default, .NET Core will actually be looking
to open up its frontend at port 5002
and we have to make sure that we are using
https instead of http.
Once that launch.json is edited,
we can then move on to making changes
within the .NET Core project.
First, you want to open up that csproj and
you can honestly remove all of this as
it's no longer needed because our frontend is now
sitting within a different project type,
and the proxying between the frontend
and the backend is happening from the frontend,
not from the backend, so all you need
is what target framework you're currently using.
In this case, we're doing .NET Core 6.0.
From there, we then need to actually change
our properties of the .NET Core project,
just so we can simply say do not launch a browser.
Go to ''Debug'' and uncheck launch browser.
Now the only browser being
launched will be coming from the frontend,
not from the frontend and the backend.
Once we've done that, we can then
right-click on the ''Solution'' as a whole
and we actually need to
edit which start-up projects we will be using.
Currently, the .NET Core project is the startup project,
but we actually need to have
both of them startup at the same time.
I normally move the frontend to the top,
just in case Visual Studio does
some weird thing where it starts one than the other.
I want to make sure the frontend is
happening first and that's where the proxy work
will be coming from. Now let's run it.
Once we run it, we'll see the same very similar tasks
being run with npm start,
though npm start might be a little bit different,
and that is because proxy work has added
some changes to our launch.json.
You can now see our proxy is created at localhost:5001.
Now we just wait for the magic to happen.
We have our browser popping up at port 5002,
and then you'll also see another command prompt,
and that is just simply the backend
actually starting up in .NET Core
doing what it has to do.
To make sure we have everything correct,
we actually are going to look at our fetched data,
which is supposed to be coming from .NET Core.
However, if we stop it and just make sure this is real,
we're going to go to our weather forecasts
and we're going to
actually put a break point and start it up again.
Now 5002 is loading, that's great.
Let's go to fetch data.
Now our weather forecast has caused us to pause.
We're going to hit ''Continue'' a few times
until we get back to the browser.
Now that's done, you see that all of
the weather data has been
actually pushed to the frontend.
We are now aware that the frontend
and the backend are both connected.
I know it might seem a little weird as to, well,
why are we copying and pasting
all these files from one to the other?
It's just simply because we have
the weather forecasts already there in
the frontend of the .NET Core project
and we don't want to rebuild it all from scratch,
though you absolutely could.
Switching over to the client app
from the .NET Core project
into the Angular JavaScript project
actually would then allow
you to have access to
the JavaScript tooling that we're now making available.
Without it, you'll just have simply
TypeScript and JavaScript files,
but you won't be able to use the additional tooling
that's available in the JavaScript project type.
Now that we've completed the demos,
why don't we talk about some additional tooling that'll
actually help improve
the JavaScript and TypeScript experience?
I didn't mention that there will actually be
a way to search, import, and manage your
npm module packages within Visual Studio.
However, I was showing you a few prototypes and
that future is not been
brought completed to Visual Studio yet.
However, this is exactly what it will look like.
It will be very similar to what
the NuGet Package Manager currently looks
like right now when you open it in Visual Studio,
you'll be able to search.
You'll see a description,
and you'll be able to just simply
click ''Install Package'',
and you'll be able to see all your packages
in the solution explorer
that you have installed via Visual Studio.
That is soon to come.
But if you do want to enhance your experience
a little bit more when you're using this,
something I would suggest is actually downloading
the NPM Task Runner Explorer extension.
It is available in
the extension marketplace actually now.
It is an extension that will allow you to actually run
your npm scripts like npm start, npm build,
things like that, actually within Visual Studio
instead of having to open
a command prompt if there's ever
anything that you feel like is missing from Visual Studio.
It is actually available now but
doesn't exactly work the way you might
want it to with .NET Core projects
being that the package.json is
so far nested that
it's hard for the extension to find it.
However, with the new JavaScript project type,
the package.json can be found a lot easier
and you can actually run the scripts
just like how it shows in this picture below.
Another exception that might actually be great
for anyone that will be
using the new JavaScript project type
and doing Angular development at all is
the Angular Language Service extension
available within Visual Studio.
It is also now available in the marketplace
and it does work well with .NET Core projects.
As long as you have some type of
Angular project in Visual Studio,
this extension would work.
What's next?
Well, we're hoping to release
this new product type by the end of the summer.
So please be on the lookout for that
as I'm super excited of what's to come
and the experience that'll bring
to frontend developers in Visual Studio.
With this new experience,
we have a promise to bring continuous support
for JavaScript and TypeScript frameworks
with the ones that we currently have,
making sure that everything stays up to date.
But as well to support any new booming and
up and coming frameworks
that might be taking the world by storm.
We also promised to do the same for
any JavaScript and TypeScript unit testing frameworks,
as we want to make sure Visual Studio stays
up to date with the proper tooling needed.
As we move forward, we do want
to see continuous improvements
to the .NET Core SPA experience.
We do have a couple of plans for that such as
hopefully one day the two project solution
comes out of the box.
We don't have a timeline for that
but it is something that we're
looking forward to in researching.
However, if you feel like we're missing
anything in our experience so far,
anything that you would love to see,
please submit your feedback and ideas to aka.ms/JSPS.
I'd love to hear what any ideas you would like to
see within this new JavaScript experience,
and let me and my team know what
we can do better for you. Thank you.