Examine strategies for managing large complex JavaScript Firebase projects and learn how to share code with NPM packages https://angularfirebase.com/lessons/how-to-structure-a-large-web-app-project/

- Monorepos vs multirepos: https://redfin.engineering/well-never-know-whether-monorepos-are-better-2c08ab9324c0
- Firebase multihosting video: https://youtu.be/NrkFBmBFA6k
2024-02-04T07:17:34.898Z
nova-2
2-general-nova
2024-01-09.29447
30089e05-99d1-4376-b32e-c263170674af
a0150aa1-486b-43ed-931c-a4edb4ab80fa
c1103d5caa3f4281ee19bab7fe05dde44e0b94ca640e8ac2b2159b1319e38514
67875a7f-c9c4-48a0-aa55-5bdb8a91c34a
deprecated
Code reusability is one of the most important concepts in all of software development.
But what often happens is you write some code in one app and then you want to reuse it in a different app down the road, maybe your back end Cloud functions or a different front end app, but it's not very easy to reuse that code because it's tightly coupled to one specific app.
In today's video, we'll look at code sharing strategies specifically for large JavaScript projects.
If you're new to the channel, like and subscribe and grab the full source code from Angular Firebase dotcom.
And I'm also giving away some free swag with this video.
All you have to do is leave a comment below, and I'll randomly pick a winner by this weekend.
Let's imagine that we have 3 different apps.
We have a customer facing Angular app.
We used Vue to build an admin app, and then we have a Cloud Functions back end with Node.
Js.
Our goal with this video is to orchestrate all these projects with Firebase and then also share common business logic and TypeScript interfaces between them.
So I just have an empty directory opened up here in Versus Code, and the first thing I'll do is generate our Angular front end by running the ng new command.
This just generates a basic Angular app, but the important thing to keep in mind here is that this project has its own package JSON and it also has its own dedicated Git repository.
Now to add some complexity, I'll also generate a Vue app with the Vue CLI.
And just like Angular, it has its own package JSON and its own Git repo.
Then we'll give our app a back end by initializing Firebase.
And I'm going to select functions and hosting as the Firebase features.
The functions directory is also a Node.
Js project, so it has its own package JSON.
And then it doesn't have a Git repository by default, but you can initialize 1 in there as well.
So now we have Firebase initialized in this parent directory, and we can orchestrate the deployments for our front end apps and our functions.
I have an entire video on multisite hosting, so make sure to check that out.
But what we can do in this Firebase JSON file is set up multiple hosting targets so we can deploy our Angular app to 1 l and our view app to a different URL but have them share the same Firebase project.
At this point, we have a project with multiple apps and we have a big decision to make.
Do we structure this as a monorepo or maintain multiple repos?
1st, let's look at monorepos and try to decide if that would be a good decision or not.
To make this a monorepo, we would first remove the Git repositories in the individual apps and then set up a single Git repo in the root of this project.
This means that anytime code is committed, it's immediately synchronized to all apps within the project.
And it gives you a single centralized place to manage all pull requests and issues that come up.
A perfect example of a monorepo is Angular itself.
For example, you have dozens of different projects within the Angular monorepo such just the router, reactive forms, etcetera.
All these packages share the same versioning, so there's never any question about whether or not you're using the right package.
So if you have a project that has many different developers contributing or has many different subprojects nested under it, I would highly recommend going the monorepo approach.
And there's some good tools out there to help you get the job done right.
There's a package called lerna, which is used by the Firebase SDK and many other JavaScript projects.
And there's also NX from Narwhal which is an awesome tool for creating monorepos with Angular.
But monorepos aren't the right choice for every project.
They also have their downsides.
A pretty big drawback is a loss in flexibility.
It's a lot easier to test and deploy an individual repo than it is to deploy and test an entire mono repo.
And when you have small focused projects, you're free to work on them with whatever tooling and best practices that you established.
That level of flexibility tends to be very beneficial to small teams and individuals where it might add chaos if you're a large enterprise team with a 100 developers.
Because I'm an independent developer and only have a few projects nested Within this workspace, I'm going to go with the multi repo approach.
Now let's look at how we can reuse code between these projects by using a shared library with npm.
I'm gonna go ahead and create another directory here called shared stuff and then we'll CD into that directory and run npm init to start a new package from scratch.
The purpose of this library is to share code between our projects by being installed as a dependency in whatever app needs to use it.
The first thing I'll do is create an index TS file inside of here.
And then if we look in the package JSON, you'll notice that it has a main property that points to index JS.
That's just the main entry point for this package.
Then we also want to share typings in this project.
So I'm going to set up the types property and have that point to index.d.ts.
TypeScript will generate these files for us automatically when we build our code here in a minute.
A really common use case is to share interfaces between projects.
So I might have a user interface that I want to use in my Angular app, my admin app, and also in my Cloud Functions.
If I were to declare this interface in my Angular front end, for example, I wouldn't be able to import it anywhere else.
But in a shared package, we can use it in any other JavaScript project.
Then we can also export business logic here as well.
So I'll just create a function called create ID that returns a random string.
So now we need to package our library so it can be consumed by other projects.
For a simple use case like this, we can just use TypeScript directly.
But for more complex Libraries, you'll probably wanna use something like roll up.
To build our library, we need to build script.
So we'll go into the package JSON and the build command is just tsc index dot ts and then flagd to also include the typings.
Now we can just run npm run build from the command line and that will package up everything with our index.
Js and typings.
Now we're ready to put our shared library to use.
If your company has a lot of shared packages, I would getting an NPM organization set up so you can install everything remotely.
But for now, we'll just go ahead and install our shared library locally.
We'll start by seeding into our Angular front end, and then we'll run npm install with the path to the folder that contains the shared stuff.
Then if we open our package JSON in the Angular app, you'll see that we now have a dependency of the shared stuff library.
And we can start using it just like we would with any other npm package.
For example, I'll go into the App component here, then I'll import that create ID function that we wrote inside of the library.
Then we'll use it to replace the title property on the app component.
Then when we serve the app, it generates the title as expected.
Now we can go into our Vue app or our functions and follow the exact same process and get the exact same results.
Obviously, this is a lot more reliable than trying to copy and paste code between projects.
X.
But it can also really help with tooling especially when you have shared interfaces.
All I have to do is start typing the interface and Versus Code will know to auto import it And we'll also get the IntelliSense autocomplete for all of our shared code.
So that's how you create a shared JavaScript library for your project.
It can get a lot more complex from there with packaging and things like that.
But the final thing that we wanna consider here is that we have this root project directory, but it's currently not under source control.
The content in this directory is just configuration stuff, so the Firebase CLI knows where to deploy our apps.
But you probably want it under version control as well.
So we'll initialize a git repository here, then we'll say git add and git commit.
When you create a git repository that has other git repositories nested inside of it, The child repositories will be treated as submodules.
I'm gonna go ahead and push this code to GitHub.
And if we look at the submodules, you can See that they're just grayed out folders, and we can't actually click inside of them.
In this context, we're just using the submodules as placeholders to show what our actual project structure looks like.
In other contexts, they can be a pain to deal with.
But with our multi repo approach, we're managing each one individually so they can be thought of as their own separate Projects.
I'm gonna go ahead and wrap things up there.
Hopefully, this video helped you understand how to share code between large JavaScript and or Firebase projects.
If you have any questions, leave me a comment below.
And if you wanna learn about more advanced concepts, consider upgrading to a pro membership at angularfirebase dotcom.
You'll get access to my full courses and a whole bunch of other exclusive content.
Thanks for watching, and I'll talk to you soon.

Speaker 0: Code reusability is one of the most important concepts in all of software development. But what often happens is you write some code in one app and then you want to reuse it in a different app down the road, maybe your back end Cloud functions or a different front end app, but it's not very easy to reuse that code because it's tightly coupled to one specific app. In today's video, we'll look at code sharing strategies specifically for large JavaScript projects. If you're new to the channel, like and subscribe and grab the full source code from Angular Firebase dotcom. And I'm also giving away some free swag with this video.

All you have to do is leave a comment below, and I'll randomly pick a winner by this weekend. Let's imagine that we have 3 different apps. We have a customer facing Angular app. We used Vue to build an admin app, and then we have a Cloud Functions back end with Node. Js.

Our goal with this video is to orchestrate all these projects with Firebase and then also share common business logic and TypeScript interfaces between them. So I just have an empty directory opened up here in Versus Code, and the first thing I'll do is generate our Angular front end by running the ng new command. This just generates a basic Angular app, but the important thing to keep in mind here is that this project has its own package JSON and it also has its own dedicated Git repository. Now to add some complexity, I'll also generate a Vue app with the Vue CLI. And just like Angular, it has its own package JSON and its own Git repo.

Then we'll give our app a back end by initializing Firebase. And I'm going to select functions and hosting as the Firebase features. The functions directory is also a Node. Js project, so it has its own package JSON. And then it doesn't have a Git repository by default, but you can initialize 1 in there as well.

So now we have Firebase initialized in this parent directory, and we can orchestrate the deployments for our front end apps and our functions. I have an entire video on multisite hosting, so make sure to check that out. But what we can do in this Firebase JSON file is set up multiple hosting targets so we can deploy our Angular app to 1 l and our view app to a different URL but have them share the same Firebase project. At this point, we have a project with multiple apps and we have a big decision to make. Do we structure this as a monorepo or maintain multiple repos?

1st, let's look at monorepos and try to decide if that would be a good decision or not. To make this a monorepo, we would first remove the Git repositories in the individual apps and then set up a single Git repo in the root of this project. This means that anytime code is committed, it's immediately synchronized to all apps within the project. And it gives you a single centralized place to manage all pull requests and issues that come up. A perfect example of a monorepo is Angular itself.

For example, you have dozens of different projects within the Angular monorepo such just the router, reactive forms, etcetera. All these packages share the same versioning, so there's never any question about whether or not you're using the right package. So if you have a project that has many different developers contributing or has many different subprojects nested under it, I would highly recommend going the monorepo approach. And there's some good tools out there to help you get the job done right. There's a package called lerna, which is used by the Firebase SDK and many other JavaScript projects.

And there's also NX from Narwhal which is an awesome tool for creating monorepos with Angular. But monorepos aren't the right choice for every project. They also have their downsides. A pretty big drawback is a loss in flexibility. It's a lot easier to test and deploy an individual repo than it is to deploy and test an entire mono repo.

And when you have small focused projects, you're free to work on them with whatever tooling and best practices that you established. That level of flexibility tends to be very beneficial to small teams and individuals where it might add chaos if you're a large enterprise team with a 100 developers. Because I'm an independent developer and only have a few projects nested Within this workspace, I'm going to go with the multi repo approach. Now let's look at how we can reuse code between these projects by using a shared library with npm. I'm gonna go ahead and create another directory here called shared stuff and then we'll CD into that directory and run npm init to start a new package from scratch.

The purpose of this library is to share code between our projects by being installed as a dependency in whatever app needs to use it. The first thing I'll do is create an index TS file inside of here. And then if we look in the package JSON, you'll notice that it has a main property that points to index JS. That's just the main entry point for this package. Then we also want to share typings in this project.

So I'm going to set up the types property and have that point to index.d.ts. TypeScript will generate these files for us automatically when we build our code here in a minute. A really common use case is to share interfaces between projects. So I might have a user interface that I want to use in my Angular app, my admin app, and also in my Cloud Functions. If I were to declare this interface in my Angular front end, for example, I wouldn't be able to import it anywhere else.

But in a shared package, we can use it in any other JavaScript project. Then we can also export business logic here as well. So I'll just create a function called create ID that returns a random string. So now we need to package our library so it can be consumed by other projects. For a simple use case like this, we can just use TypeScript directly.

But for more complex Libraries, you'll probably wanna use something like roll up. To build our library, we need to build script. So we'll go into the package JSON and the build command is just tsc index dot ts and then flagd to also include the typings. Now we can just run npm run build from the command line and that will package up everything with our index. Js and typings.

Now we're ready to put our shared library to use. If your company has a lot of shared packages, I would getting an NPM organization set up so you can install everything remotely. But for now, we'll just go ahead and install our shared library locally. We'll start by seeding into our Angular front end, and then we'll run npm install with the path to the folder that contains the shared stuff. Then if we open our package JSON in the Angular app, you'll see that we now have a dependency of the shared stuff library.

And we can start using it just like we would with any other npm package. For example, I'll go into the App component here, then I'll import that create ID function that we wrote inside of the library. Then we'll use it to replace the title property on the app component. Then when we serve the app, it generates the title as expected. Now we can go into our Vue app or our functions and follow the exact same process and get the exact same results.

Obviously, this is a lot more reliable than trying to copy and paste code between projects. X. But it can also really help with tooling especially when you have shared interfaces. All I have to do is start typing the interface and Versus Code will know to auto import it And we'll also get the IntelliSense autocomplete for all of our shared code. So that's how you create a shared JavaScript library for your project.

It can get a lot more complex from there with packaging and things like that. But the final thing that we wanna consider here is that we have this root project directory, but it's currently not under source control. The content in this directory is just configuration stuff, so the Firebase CLI knows where to deploy our apps. But you probably want it under version control as well. So we'll initialize a git repository here, then we'll say git add and git commit.

When you create a git repository that has other git repositories nested inside of it, The child repositories will be treated as submodules. I'm gonna go ahead and push this code to GitHub. And if we look at the submodules, you can See that they're just grayed out folders, and we can't actually click inside of them. In this context, we're just using the submodules as placeholders to show what our actual project structure looks like. In other contexts, they can be a pain to deal with.

But with our multi repo approach, we're managing each one individually so they can be thought of as their own separate Projects. I'm gonna go ahead and wrap things up there. Hopefully, this video helped you understand how to share code between large JavaScript and or Firebase projects. If you have any questions, leave me a comment below. And if you wanna learn about more advanced concepts, consider upgrading to a pro membership at angularfirebase dotcom.

You'll get access to my full courses and a whole bunch of other exclusive content. Thanks for watching, and I'll talk to you soon.
Code reusability is one of the most important concepts in all of software development. But what often happens is you write some code in one app and then you want to reuse it in a different app down the road, maybe your back end Cloud functions or a different front end app, but it's not very easy to reuse that code because it's tightly coupled to one specific app. In today's video, we'll look at code sharing strategies specifically for large JavaScript projects. If you're new to the channel, like and subscribe and grab the full source code from Angular Firebase dotcom. And I'm also giving away some free swag with this video. All you have to do is leave a comment below, and I'll randomly pick a winner by this weekend. Let's imagine that we have 3 different apps. We have a customer facing Angular app. We used Vue to build an admin app, and then we have a Cloud Functions back end with Node. Js. Our goal with this video is to orchestrate all these projects with Firebase and then also share common business logic and TypeScript interfaces between them.
software development
youtube
streaming
software
multimedia
video gaming
So I just have an empty directory opened up here in Versus Code, and the first thing I'll do is generate our Angular front end by running the ng new command. This just generates a basic Angular app, but the important thing to keep in mind here is that this project has its own package JSON and it also has its own dedicated Git repository. Now to add some complexity, I'll also generate a Vue app with the Vue CLI. And just like Angular, it has its own package JSON and its own Git repo. Then we'll give our app a back end by initializing Firebase. And I'm going to select functions and hosting as the Firebase features. The functions directory is also a Node. Js project, so it has its own package JSON. And then it doesn't have a Git repository by default, but you can initialize 1 in there as well. So now we have Firebase initialized in this parent directory, and we can orchestrate the deployments for our front end apps and our functions. I have an entire video on multisite hosting, so make sure to check that out. But what we can do in this Firebase JSON file is set up multiple hosting targets so we can deploy our Angular app to 1 l and our view app to a different URL but have them share the same Firebase project. At this point, we have a project with multiple apps and we have a big decision to make. Do we structure this as a monorepo or maintain multiple repos?
1st, let's look at monorepos and try to decide if that would be a good decision or not. To make this a monorepo, we would first remove the Git repositories in the individual apps and then set up a single Git repo in the root of this project. This means that anytime code is committed, it's immediately synchronized to all apps within the project.
software
And it gives you a single centralized place to manage all pull requests and issues that come up. A perfect example of a monorepo is Angular itself. For example, you have dozens of different projects within the Angular monorepo such just the router, reactive forms, etcetera.
All these packages share the same versioning, so there's never any question about whether or not you're using the right package. So if you have a project that has many different developers contributing or has many different subprojects nested under it, I would highly recommend going the monorepo approach. And there's some good tools out there to help you get the job done right.
software
software development
There's a package called lerna, which is used by the Firebase SDK and many other JavaScript projects. And there's also NX from Narwhal which is an awesome tool for creating monorepos with Angular. But monorepos aren't the right choice for every project. They also have their downsides. A pretty big drawback is a loss in flexibility. It's a lot easier to test and deploy an individual repo than it is to deploy and test an entire mono repo.
And when you have small focused projects, you're free to work on them with whatever tooling and best practices that you established. That level of flexibility tends to be very beneficial to small teams and individuals where it might add chaos if you're a large enterprise team with a 100 developers. Because I'm an independent developer and only have a few projects nested Within this workspace, I'm going to go with the multi repo approach. Now let's look at how we can reuse code between these projects by using a shared library with npm. I'm gonna go ahead and create another directory here called shared stuff and then we'll CD into that directory and run npm init to start a new package from scratch. The purpose of this library is to share code between our projects by being installed as a dependency in whatever app needs to use it.
software development
software
management
The first thing I'll do is create an index TS file inside of here. And then if we look in the package JSON, you'll notice that it has a main property that points to index JS.
That's just the main entry point for this package. Then we also want to share typings in this project. So I'm going to set up the types property and have that point to index.d.ts. TypeScript will generate these files for us automatically when we build our code here in a minute. A really common use case is to share interfaces between projects. So I might have a user interface that I want to use in my Angular app, my admin app, and also in my Cloud Functions.
software development
software
programming
If I were to declare this interface in my Angular front end, for example, I wouldn't be able to import it anywhere else. But in a shared package, we can use it in any other JavaScript project.
Then we can also export business logic here as well. So I'll just create a function called create ID that returns a random string. So now we need to package our library so it can be consumed by other projects. For a simple use case like this, we can just use TypeScript directly. But for more complex Libraries, you'll probably wanna use something like roll up. To build our library, we need to build script. So we'll go into the package JSON and the build command is just tsc index dot ts and then flagd to also include the typings.
programming
software development
software
Now we can just run npm run build from the command line and that will package up everything with our index. Js and typings. Now we're ready to put our shared library to use. If your company has a lot of shared packages, I would getting an NPM organization set up so you can install everything remotely. But for now, we'll just go ahead and install our shared library locally. We'll start by seeding into our Angular front end, and then we'll run npm install with the path to the folder that contains the shared stuff. Then if we open our package JSON in the Angular app, you'll see that we now have a dependency of the shared stuff library. And we can start using it just like we would with any other npm package. For example, I'll go into the App component here, then I'll import that create ID function that we wrote inside of the library. Then we'll use it to replace the title property on the app component.
Then when we serve the app, it generates the title as expected. Now we can go into our Vue app or our functions and follow the exact same process and get the exact same results. Obviously, this is a lot more reliable than trying to copy and paste code between projects. X. But it can also really help with tooling especially when you have shared interfaces. All I have to do is start typing the interface and Versus Code will know to auto import it And we'll also get the IntelliSense autocomplete for all of our shared code. So that's how you create a shared JavaScript library for your project. It can get a lot more complex from there with packaging and things like that.
software
software development
infrastructure
programming
But the final thing that we wanna consider here is that we have this root project directory, but it's currently not under source control. The content in this directory is just configuration stuff, so the Firebase CLI knows where to deploy our apps. But you probably want it under version control as well. So we'll initialize a git repository here, then we'll say git add and git commit. When you create a git repository that has other git repositories nested inside of it, The child repositories will be treated as submodules. I'm gonna go ahead and push this code to GitHub. And if we look at the submodules, you can See that they're just grayed out folders, and we can't actually click inside of them. In this context, we're just using the submodules as placeholders to show what our actual project structure looks like. In other contexts, they can be a pain to deal with. But with our multi repo approach, we're managing each one individually so they can be thought of as their own separate Projects. I'm gonna go ahead and wrap things up there. Hopefully, this video helped you understand how to share code between large JavaScript and or Firebase projects. If you have any questions, leave me a comment below. And if you wanna learn about more advanced concepts, consider upgrading to a pro membership at angularfirebase dotcom. You'll get access to my full courses and a whole bunch of other exclusive content. Thanks for watching, and I'll talk to you soon.
Code reusability is one of the most important concepts in all of software development. But what often happens is you write some code in one app and then you want to reuse it in a different app down the road, maybe your back end Cloud functions or a different front end app, but it's not very easy to reuse that code because it's tightly coupled to one specific app. In today's video, we'll look at code sharing strategies specifically for large JavaScript projects. If you're new to the channel, like and subscribe and grab the full source code from Angular Firebase dotcom. And I'm also giving away some free swag with this video. All you have to do is leave a comment below, and I'll randomly pick a winner by this weekend. Let's imagine that we have 3 different apps. We have a customer facing Angular app. We used Vue to build an admin app, and then we have a Cloud Functions back end with Node. Js. Our goal with this video is to orchestrate all these projects with Firebase and then also share common business logic and TypeScript interfaces between them. So I just have an empty directory opened up here in Versus Code, and the first thing I'll do is generate our Angular front end by running the ng new command. This just generates a basic Angular app, but the important thing to keep in mind here is that this project has its own package JSON and it also has its own dedicated Git repository. Now to add some complexity, I'll also generate a Vue app with the Vue CLI. And just like Angular, it has its own package JSON and its own Git repo. Then we'll give our app a back end by initializing Firebase. And I'm going to select functions and hosting as the Firebase features. The functions directory is also a Node. Js project, so it has its own package JSON. And then it doesn't have a Git repository by default, but you can initialize 1 in there as well. So now we have Firebase initialized in this parent directory, and we can orchestrate the deployments for our front end apps and our functions. I have an entire video on multisite hosting, so make sure to check that out. But what we can do in this Firebase JSON file is set up multiple hosting targets so we can deploy our Angular app to 1 l and our view app to a different URL but have them share the same Firebase project. At this point, we have a project with multiple apps and we have a big decision to make. Do we structure this as a monorepo or maintain multiple repos? 1st, let's look at monorepos and try to decide if that would be a good decision or not. To make this a monorepo, we would first remove the Git repositories in the individual apps and then set up a single Git repo in the root of this project. This means that anytime code is committed, it's immediately synchronized to all apps within the project. And it gives you a single centralized place to manage all pull requests and issues that come up. A perfect example of a monorepo is Angular itself. For example, you have dozens of different projects within the Angular monorepo such just the router, reactive forms, etcetera. All these packages share the same versioning, so there's never any question about whether or not you're using the right package. So if you have a project that has many different developers contributing or has many different subprojects nested under it, I would highly recommend going the monorepo approach. And there's some good tools out there to help you get the job done right. There's a package called lerna, which is used by the Firebase SDK and many other JavaScript projects. And there's also NX from Narwhal which is an awesome tool for creating monorepos with Angular. But monorepos aren't the right choice for every project. They also have their downsides. A pretty big drawback is a loss in flexibility. It's a lot easier to test and deploy an individual repo than it is to deploy and test an entire mono repo. And when you have small focused projects, you're free to work on them with whatever tooling and best practices that you established. That level of flexibility tends to be very beneficial to small teams and individuals where it might add chaos if you're a large enterprise team with a 100 developers. Because I'm an independent developer and only have a few projects nested Within this workspace, I'm going to go with the multi repo approach. Now let's look at how we can reuse code between these projects by using a shared library with npm. I'm gonna go ahead and create another directory here called shared stuff and then we'll CD into that directory and run npm init to start a new package from scratch. The purpose of this library is to share code between our projects by being installed as a dependency in whatever app needs to use it. The first thing I'll do is create an index TS file inside of here. And then if we look in the package JSON, you'll notice that it has a main property that points to index JS. That's just the main entry point for this package. Then we also want to share typings in this project. So I'm going to set up the types property and have that point to index.d.ts. TypeScript will generate these files for us automatically when we build our code here in a minute. A really common use case is to share interfaces between projects. So I might have a user interface that I want to use in my Angular app, my admin app, and also in my Cloud Functions. If I were to declare this interface in my Angular front end, for example, I wouldn't be able to import it anywhere else. But in a shared package, we can use it in any other JavaScript project. Then we can also export business logic here as well. So I'll just create a function called create ID that returns a random string. So now we need to package our library so it can be consumed by other projects. For a simple use case like this, we can just use TypeScript directly. But for more complex Libraries, you'll probably wanna use something like roll up. To build our library, we need to build script. So we'll go into the package JSON and the build command is just tsc index dot ts and then flagd to also include the typings. Now we can just run npm run build from the command line and that will package up everything with our index. Js and typings. Now we're ready to put our shared library to use. If your company has a lot of shared packages, I would getting an NPM organization set up so you can install everything remotely. But for now, we'll just go ahead and install our shared library locally. We'll start by seeding into our Angular front end, and then we'll run npm install with the path to the folder that contains the shared stuff. Then if we open our package JSON in the Angular app, you'll see that we now have a dependency of the shared stuff library. And we can start using it just like we would with any other npm package. For example, I'll go into the App component here, then I'll import that create ID function that we wrote inside of the library. Then we'll use it to replace the title property on the app component. Then when we serve the app, it generates the title as expected. Now we can go into our Vue app or our functions and follow the exact same process and get the exact same results. Obviously, this is a lot more reliable than trying to copy and paste code between projects. X. But it can also really help with tooling especially when you have shared interfaces. All I have to do is start typing the interface and Versus Code will know to auto import it And we'll also get the IntelliSense autocomplete for all of our shared code. So that's how you create a shared JavaScript library for your project. It can get a lot more complex from there with packaging and things like that. But the final thing that we wanna consider here is that we have this root project directory, but it's currently not under source control. The content in this directory is just configuration stuff, so the Firebase CLI knows where to deploy our apps. But you probably want it under version control as well. So we'll initialize a git repository here, then we'll say git add and git commit. When you create a git repository that has other git repositories nested inside of it, The child repositories will be treated as submodules. I'm gonna go ahead and push this code to GitHub. And if we look at the submodules, you can See that they're just grayed out folders, and we can't actually click inside of them. In this context, we're just using the submodules as placeholders to show what our actual project structure looks like. In other contexts, they can be a pain to deal with. But with our multi repo approach, we're managing each one individually so they can be thought of as their own separate Projects. I'm gonna go ahead and wrap things up there. Hopefully, this video helped you understand how to share code between large JavaScript and or Firebase projects. If you have any questions, leave me a comment below. And if you wanna learn about more advanced concepts, consider upgrading to a pro membership at angularfirebase dotcom. You'll get access to my full courses and a whole bunch of other exclusive content. Thanks for watching, and I'll talk to you soon.
Code
code
reusability
reusability
is
is
one
one
of
of
the
the
most
most
important
important
concepts
concepts
in
in
all
all
of
of
software
software
development.
development
But
but
what
what
often
often
happens
happens
is
is
you
you
write
write
some
some
code
code
in
in
one
one
app
app
and
and
then
then
you
you
want
want
to
to
reuse
reuse
it
it
in
in
a
a
different
different
app
app
down
down
the
the
road,
road
maybe
maybe
your
your
back
back
end
end
Cloud
cloud
functions
functions
or
or
a
a
different
different
front
front
end
end
app,
app
but
but
it's
it's
not
not
very
very
easy
easy
to
to
reuse
reuse
that
that
code
code
because
because
it's
it's
tightly
tightly
coupled
coupled
to
to
one
one
specific
specific
app.
app
In
in
today's
today's
video,
video
we'll
we'll
look
look
at
at
code
code
sharing
sharing
strategies
strategies
specifically
specifically
for
for
large
large
JavaScript
javascript
projects.
projects
If
if
you're
you're
new
new
to
to
the
the
channel,
channel
like
like
and
and
subscribe
subscribe
and
and
grab
grab
the
the
full
full
source
source
code
code
from
from
Angular
angular
Firebase
firebase
dotcom.
dotcom
And
and
I'm
i'm
also
also
giving
giving
away
away
some
some
free
free
swag
swag
with
with
this
this
video.
video
All
all
you
you
have
have
to
to
do
do
is
is
leave
leave
a
a
comment
comment
below,
below
and
and
I'll
i'll
randomly
randomly
pick
pick
a
a
winner
winner
by
by
this
this
weekend.
weekend
Let's
let's
imagine
imagine
that
that
we
we
have
have
3
3
different
different
apps.
apps
We
we
have
have
a
a
customer
customer
facing
facing
Angular
angular
app.
app
We
we
used
used
Vue
vue
to
to
build
build
an
an
admin
admin
app,
app
and
and
then
then
we
we
have
have
a
a
Cloud
cloud
Functions
functions
back
back
end
end
with
with
Node.
node
Js.
js
Our
our
goal
goal
with
with
this
this
video
video
is
is
to
to
orchestrate
orchestrate
all
all
these
these
projects
projects
with
with
Firebase
firebase
and
and
then
then
also
also
share
share
common
common
business
business
logic
logic
and
and
TypeScript
typescript
interfaces
interfaces
between
between
them.
them
So
so
I
i
just
just
have
have
an
an
empty
empty
directory
directory
opened
opened
up
up
here
here
in
in
Versus
versus
Code,
code
and
and
the
the
first
first
thing
thing
I'll
i'll
do
do
is
is
generate
generate
our
our
Angular
angular
front
front
end
end
by
by
running
running
the
the
ng
ng
new
new
command.
command
This
this
just
just
generates
generates
a
a
basic
basic
Angular
angular
app,
app
but
but
the
the
important
important
thing
thing
to
to
keep
keep
in
in
mind
mind
here
here
is
is
that
that
this
this
project
project
has
has
its
its
own
own
package
package
JSON
json
and
and
it
it
also
also
has
has
its
its
own
own
dedicated
dedicated
Git
git
repository.
repository
Now
now
to
to
add
add
some
some
complexity,
complexity
I'll
i'll
also
also
generate
generate
a
a
Vue
vue
app
app
with
with
the
the
Vue
vue
CLI.
cli
And
and
just
just
like
like
Angular,
angular
it
it
has
has
its
its
own
own
package
package
JSON
json
and
and
its
its
own
own
Git
git
repo.
repo
Then
then
we'll
we'll
give
give
our
our
app
app
a
a
back
back
end
end
by
by
initializing
initializing
Firebase.
firebase
And
and
I'm
i'm
going
going
to
to
select
select
functions
functions
and
and
hosting
hosting
as
as
the
the
Firebase
firebase
features.
features
The
the
functions
functions
directory
directory
is
is
also
also
a
a
Node.
node
Js
js
project,
project
so
so
it
it
has
has
its
its
own
own
package
package
JSON.
json
And
and
then
then
it
it
doesn't
doesn't
have
have
a
a
Git
git
repository
repository
by
by
default,
default
but
but
you
you
can
can
initialize
initialize
1
1
in
in
there
there
as
as
well.
well
So
so
now
now
we
we
have
have
Firebase
firebase
initialized
initialized
in
in
this
this
parent
parent
directory,
directory
and
and
we
we
can
can
orchestrate
orchestrate
the
the
deployments
deployments
for
for
our
our
front
front
end
end
apps
apps
and
and
our
our
functions.
functions
I
i
have
have
an
an
entire
entire
video
video
on
on
multisite
multisite
hosting,
hosting
so
so
make
make
sure
sure
to
to
check
check
that
that
out.
out
But
but
what
what
we
we
can
can
do
do
in
in
this
this
Firebase
firebase
JSON
json
file
file
is
is
set
set
up
up
multiple
multiple
hosting
hosting
targets
targets
so
so
we
we
can
can
deploy
deploy
our
our
Angular
angular
app
app
to
to
1
1
l
l
and
and
our
our
view
view
app
app
to
to
a
a
different
different
URL
url
but
but
have
have
them
them
share
share
the
the
same
same
Firebase
firebase
project.
project
At
at
this
this
point,
point
we
we
have
have
a
a
project
project
with
with
multiple
multiple
apps
apps
and
and
we
we
have
have
a
a
big
big
decision
decision
to
to
make.
make
Do
do
we
we
structure
structure
this
this
as
as
a
a
monorepo
monorepo
or
or
maintain
maintain
multiple
multiple
repos?
repos
1st,
1st
let's
let's
look
look
at
at
monorepos
monorepos
and
and
try
try
to
to
decide
decide
if
if
that
that
would
would
be
be
a
a
good
good
decision
decision
or
or
not.
not
To
to
make
make
this
this
a
a
monorepo,
monorepo
we
we
would
would
first
first
remove
remove
the
the
Git
git
repositories
repositories
in
in
the
the
individual
individual
apps
apps
and
and
then
then
set
set
up
up
a
a
single
single
Git
git
repo
repo
in
in
the
the
root
root
of
of
this
this
project.
project
This
this
means
means
that
that
anytime
anytime
code
code
is
is
committed,
committed
it's
it's
immediately
immediately
synchronized
synchronized
to
to
all
all
apps
apps
within
within
the
the
project.
project
And
and
it
it
gives
gives
you
you
a
a
single
single
centralized
centralized
place
place
to
to
manage
manage
all
all
pull
pull
requests
requests
and
and
issues
issues
that
that
come
come
up.
up
A
a
perfect
perfect
example
example
of
of
a
a
monorepo
monorepo
is
is
Angular
angular
itself.
itself
For
for
example,
example
you
you
have
have
dozens
dozens
of
of
different
different
projects
projects
within
within
the
the
Angular
angular
monorepo
monorepo
such
such
just
just
the
the
router,
router
reactive
reactive
forms,
forms
etcetera.
etcetera
All
all
these
these
packages
packages
share
share
the
the
same
same
versioning,
versioning
so
so
there's
there's
never
never
any
any
question
question
about
about
whether
whether
or
or
not
not
you're
you're
using
using
the
the
right
right
package.
package
So
so
if
if
you
you
have
have
a
a
project
project
that
that
has
has
many
many
different
different
developers
developers
contributing
contributing
or
or
has
has
many
many
different
different
subprojects
subprojects
nested
nested
under
under
it,
it
I
i
would
would
highly
highly
recommend
recommend
going
going
the
the
monorepo
monorepo
approach.
approach
And
and
there's
there's
some
some
good
good
tools
tools
out
out
there
there
to
to
help
help
you
you
get
get
the
the
job
job
done
done
right.
right
There's
there's
a
a
package
package
called
called
lerna,
lerna
which
which
is
is
used
used
by
by
the
the
Firebase
firebase
SDK
sdk
and
and
many
many
other
other
JavaScript
javascript
projects.
projects
And
and
there's
there's
also
also
NX
nx
from
from
Narwhal
narwhal
which
which
is
is
an
an
awesome
awesome
tool
tool
for
for
creating
creating
monorepos
monorepos
with
with
Angular.
angular
But
but
monorepos
monorepos
aren't
aren't
the
the
right
right
choice
choice
for
for
every
every
project.
project
They
they
also
also
have
have
their
their
downsides.
downsides
A
a
pretty
pretty
big
big
drawback
drawback
is
is
a
a
loss
loss
in
in
flexibility.
flexibility
It's
it's
a
a
lot
lot
easier
easier
to
to
test
test
and
and
deploy
deploy
an
an
individual
individual
repo
repo
than
than
it
it
is
is
to
to
deploy
deploy
and
and
test
test
an
an
entire
entire
mono
mono
repo.
repo
And
and
when
when
you
you
have
have
small
small
focused
focused
projects,
projects
you're
you're
free
free
to
to
work
work
on
on
them
them
with
with
whatever
whatever
tooling
tooling
and
and
best
best
practices
practices
that
that
you
you
established.
established
That
that
level
level
of
of
flexibility
flexibility
tends
tends
to
to
be
be
very
very
beneficial
beneficial
to
to
small
small
teams
teams
and
and
individuals
individuals
where
where
it
it
might
might
add
add
chaos
chaos
if
if
you're
you're
a
a
large
large
enterprise
enterprise
team
team
with
with
a
a
100
100
developers.
developers
Because
because
I'm
i'm
an
an
independent
independent
developer
developer
and
and
only
only
have
have
a
a
few
few
projects
projects
nested
nested
Within
within
this
this
workspace,
workspace
I'm
i'm
going
going
to
to
go
go
with
with
the
the
multi
multi
repo
repo
approach.
approach
Now
now
let's
let's
look
look
at
at
how
how
we
we
can
can
reuse
reuse
code
code
between
between
these
these
projects
projects
by
by
using
using
a
a
shared
shared
library
library
with
with
npm.
npm
I'm
i'm
gonna
gonna
go
go
ahead
ahead
and
and
create
create
another
another
directory
directory
here
here
called
called
shared
shared
stuff
stuff
and
and
then
then
we'll
we'll
CD
cd
into
into
that
that
directory
directory
and
and
run
run
npm
npm
init
init
to
to
start
start
a
a
new
new
package
package
from
from
scratch.
scratch
The
the
purpose
purpose
of
of
this
this
library
library
is
is
to
to
share
share
code
code
between
between
our
our
projects
projects
by
by
being
being
installed
installed
as
as
a
a
dependency
dependency
in
in
whatever
whatever
app
app
needs
needs
to
to
use
use
it.
it
The
the
first
first
thing
thing
I'll
i'll
do
do
is
is
create
create
an
an
index
index
TS
ts
file
file
inside
inside
of
of
here.
here
And
and
then
then
if
if
we
we
look
look
in
in
the
the
package
package
JSON,
json
you'll
you'll
notice
notice
that
that
it
it
has
has
a
a
main
main
property
property
that
that
points
points
to
to
index
index
JS.
js
That's
that's
just
just
the
the
main
main
entry
entry
point
point
for
for
this
this
package.
package
Then
then
we
we
also
also
want
want
to
to
share
share
typings
typings
in
in
this
this
project.
project
So
so
I'm
i'm
going
going
to
to
set
set
up
up
the
the
types
types
property
property
and
and
have
have
that
that
point
point
to
to
index.d.ts.
index.d.ts
TypeScript
typescript
will
will
generate
generate
these
these
files
files
for
for
us
us
automatically
automatically
when
when
we
we
build
build
our
our
code
code
here
here
in
in
a
a
minute.
minute
A
a
really
really
common
common
use
use
case
case
is
is
to
to
share
share
interfaces
interfaces
between
between
projects.
projects
So
so
I
i
might
might
have
have
a
a
user
user
interface
interface
that
that
I
i
want
want
to
to
use
use
in
in
my
my
Angular
angular
app,
app
my
my
admin
admin
app,
app
and
and
also
also
in
in
my
my
Cloud
cloud
Functions.
functions
If
if
I
i
were
were
to
to
declare
declare
this
this
interface
interface
in
in
my
my
Angular
angular
front
front
end,
end
for
for
example,
example
I
i
wouldn't
wouldn't
be
be
able
able
to
to
import
import
it
it
anywhere
anywhere
else.
else
But
but
in
in
a
a
shared
shared
package,
package
we
we
can
can
use
use
it
it
in
in
any
any
other
other
JavaScript
javascript
project.
project
Then
then
we
we
can
can
also
also
export
export
business
business
logic
logic
here
here
as
as
well.
well
So
so
I'll
i'll
just
just
create
create
a
a
function
function
called
called
create
create
ID
id
that
that
returns
returns
a
a
random
random
string.
string
So
so
now
now
we
we
need
need
to
to
package
package
our
our
library
library
so
so
it
it
can
can
be
be
consumed
consumed
by
by
other
other
projects.
projects
For
for
a
a
simple
simple
use
use
case
case
like
like
this,
this
we
we
can
can
just
just
use
use
TypeScript
typescript
directly.
directly
But
but
for
for
more
more
complex
complex
Libraries,
libraries
you'll
you'll
probably
probably
wanna
wanna
use
use
something
something
like
like
roll
roll
up.
up
To
to
build
build
our
our
library,
library
we
we
need
need
to
to
build
build
script.
script
So
so
we'll
we'll
go
go
into
into
the
the
package
package
JSON
json
and
and
the
the
build
build
command
command
is
is
just
just
tsc
tsc
index
index
dot
dot
ts
ts
and
and
then
then
flagd
flagd
to
to
also
also
include
include
the
the
typings.
typings
Now
now
we
we
can
can
just
just
run
run
npm
npm
run
run
build
build
from
from
the
the
command
command
line
line
and
and
that
that
will
will
package
package
up
up
everything
everything
with
with
our
our
index.
index
Js
js
and
and
typings.
typings
Now
now
we're
we're
ready
ready
to
to
put
put
our
our
shared
shared
library
library
to
to
use.
use
If
if
your
your
company
company
has
has
a
a
lot
lot
of
of
shared
shared
packages,
packages
I
i
would
would
getting
getting
an
an
NPM
npm
organization
organization
set
set
up
up
so
so
you
you
can
can
install
install
everything
everything
remotely.
remotely
But
but
for
for
now,
now
we'll
we'll
just
just
go
go
ahead
ahead
and
and
install
install
our
our
shared
shared
library
library
locally.
locally
We'll
we'll
start
start
by
by
seeding
seeding
into
into
our
our
Angular
angular
front
front
end,
end
and
and
then
then
we'll
we'll
run
run
npm
npm
install
install
with
with
the
the
path
path
to
to
the
the
folder
folder
that
that
contains
contains
the
the
shared
shared
stuff.
stuff
Then
then
if
if
we
we
open
open
our
our
package
package
JSON
json
in
in
the
the
Angular
angular
app,
app
you'll
you'll
see
see
that
that
we
we
now
now
have
have
a
a
dependency
dependency
of
of
the
the
shared
shared
stuff
stuff
library.
library
And
and
we
we
can
can
start
start
using
using
it
it
just
just
like
like
we
we
would
would
with
with
any
any
other
other
npm
npm
package.
package
For
for
example,
example
I'll
i'll
go
go
into
into
the
the
App
app
component
component
here,
here
then
then
I'll
i'll
import
import
that
that
create
create
ID
id
function
function
that
that
we
we
wrote
wrote
inside
inside
of
of
the
the
library.
library
Then
then
we'll
we'll
use
use
it
it
to
to
replace
replace
the
the
title
title
property
property
on
on
the
the
app
app
component.
component
Then
then
when
when
we
we
serve
serve
the
the
app,
app
it
it
generates
generates
the
the
title
title
as
as
expected.
expected
Now
now
we
we
can
can
go
go
into
into
our
our
Vue
vue
app
app
or
or
our
our
functions
functions
and
and
follow
follow
the
the
exact
exact
same
same
process
process
and
and
get
get
the
the
exact
exact
same
same
results.
results
Obviously,
obviously
this
this
is
is
a
a
lot
lot
more
more
reliable
reliable
than
than
trying
trying
to
to
copy
copy
and
and
paste
paste
code
code
between
between
projects.
projects
X.
x
But
but
it
it
can
can
also
also
really
really
help
help
with
with
tooling
tooling
especially
especially
when
when
you
you
have
have
shared
shared
interfaces.
interfaces
All
all
I
i
have
have
to
to
do
do
is
is
start
start
typing
typing
the
the
interface
interface
and
and
Versus
versus
Code
code
will
will
know
know
to
to
auto
auto
import
import
it
it
And
and
we'll
we'll
also
also
get
get
the
the
IntelliSense
intellisense
autocomplete
autocomplete
for
for
all
all
of
of
our
our
shared
shared
code.
code
So
so
that's
that's
how
how
you
you
create
create
a
a
shared
shared
JavaScript
javascript
library
library
for
for
your
your
project.
project
It
it
can
can
get
get
a
a
lot
lot
more
more
complex
complex
from
from
there
there
with
with
packaging
packaging
and
and
things
things
like
like
that.
that
But
but
the
the
final
final
thing
thing
that
that
we
we
wanna
wanna
consider
consider
here
here
is
is
that
that
we
we
have
have
this
this
root
root
project
project
directory,
directory
but
but
it's
it's
currently
currently
not
not
under
under
source
source
control.
control
The
the
content
content
in
in
this
this
directory
directory
is
is
just
just
configuration
configuration
stuff,
stuff
so
so
the
the
Firebase
firebase
CLI
cli
knows
knows
where
where
to
to
deploy
deploy
our
our
apps.
apps
But
but
you
you
probably
probably
want
want
it
it
under
under
version
version
control
control
as
as
well.
well
So
so
we'll
we'll
initialize
initialize
a
a
git
git
repository
repository
here,
here
then
then
we'll
we'll
say
say
git
git
add
add
and
and
git
git
commit.
commit
When
when
you
you
create
create
a
a
git
git
repository
repository
that
that
has
has
other
other
git
git
repositories
repositories
nested
nested
inside
inside
of
of
it,
it
The
the
child
child
repositories
repositories
will
will
be
be
treated
treated
as
as
submodules.
submodules
I'm
i'm
gonna
gonna
go
go
ahead
ahead
and
and
push
push
this
this
code
code
to
to
GitHub.
github
And
and
if
if
we
we
look
look
at
at
the
the
submodules,
submodules
you
you
can
can
See
see
that
that
they're
they're
just
just
grayed
grayed
out
out
folders,
folders
and
and
we
we
can't
can't
actually
actually
click
click
inside
inside
of
of
them.
them
In
in
this
this
context,
context
we're
we're
just
just
using
using
the
the
submodules
submodules
as
as
placeholders
placeholders
to
to
show
show
what
what
our
our
actual
actual
project
project
structure
structure
looks
looks
like.
like
In
in
other
other
contexts,
contexts
they
they
can
can
be
be
a
a
pain
pain
to
to
deal
deal
with.
with
But
but
with
with
our
our
multi
multi
repo
repo
approach,
approach
we're
we're
managing
managing
each
each
one
one
individually
individually
so
so
they
they
can
can
be
be
thought
thought
of
of
as
as
their
their
own
own
separate
separate
Projects.
projects
I'm
i'm
gonna
gonna
go
go
ahead
ahead
and
and
wrap
wrap
things
things
up
up
there.
there
Hopefully,
hopefully
this
this
video
video
helped
helped
you
you
understand
understand
how
how
to
to
share
share
code
code
between
between
large
large
JavaScript
javascript
and
and
or
or
Firebase
firebase
projects.
projects
If
if
you
you
have
have
any
any
questions,
questions
leave
leave
me
me
a
a
comment
comment
below.
below
And
and
if
if
you
you
wanna
wanna
learn
learn
about
about
more
more
advanced
advanced
concepts,
concepts
consider
consider
upgrading
upgrading
to
to
a
a
pro
pro
membership
membership
at
at
angularfirebase
angularfirebase
dotcom.
dotcom
You'll
you'll
get
get
access
access
to
to
my
my
full
full
courses
courses
and
and
a
a
whole
whole
bunch
bunch
of
of
other
other
exclusive
exclusive
content.
content
Thanks
thanks
for
for
watching,
watching
and
and
I'll
i'll
talk
talk
to
to
you
you
soon.
soon
success
The speaker discusses the difficulty of reuse in large JavaScript projects and recommends using the Angular front end and cloud functions to create multiple apps and functions. The use of monorepos and multiple repos is recommended, and the use of a shared library witherver and a file generated by TypeScript is recommended. Different methods for creating an index TS file and sharing disc depend on the app needed, and shared files are used in other projects, including creating a git repository and using sub variables for project structure. There is also a pro membership for exclusive content and course links are offered.
Big JavaScript Projects - Code Sharing
Code reusability is one of the most important concepts in all of software development. But what often happens is you write some code in one app and then you want to reuse it in a different app down the road, maybe your back end Cloud functions or a different front end app, but it's not very easy to reuse that code because it's tightly coupled to one specific app. In today's video, we'll look at code sharing strategies specifically for large JavaScript projects. If you're new to the channel, like and subscribe and grab the full source code from Angular Firebase dotcom. And I'm also giving away some free swag with this video. All you have to do is leave a comment below, and I'll randomly pick a winner by this weekend. Let's imagine that we have 3 different apps. We have a customer facing Angular app. We used Vue to build an admin app, and then we have a Cloud Functions back end with Node. Js. Our goal with this video is to orchestrate all these projects with Firebase and then also share common business logic and TypeScript interfaces between them. So I just have an empty directory opened up here in Versus Code, and the first thing I'll do is generate our Angular front end by running the ng new command. This just generates a basic Angular app, but the important thing to keep in mind here is that this project has its own package JSON and it also has its own dedicated Git repository. Now to add some complexity, I'll also generate a Vue app with the Vue CLI. And just like Angular, it has its own package JSON and its own Git repo. Then we'll give our app a back end by initializing Firebase. And I'm going to select functions and hosting as the Firebase features. The functions directory is also a Node. Js project, so it has its own package JSON. And then it doesn't have a Git repository by default, but you can initialize 1 in there as well. So now we have Firebase initialized in this parent directory, and we can orchestrate the deployments for our front end apps and our functions. I have an entire video on multisite hosting, so make sure to check that out. But what we can do in this Firebase JSON file is set up multiple hosting targets so we can deploy our Angular app to 1 l and our view app to a different URL but have them share the same Firebase project. At this point, we have a project with multiple apps and we have a big decision to make. Do we structure this as a monorepo or maintain multiple repos? 1st, let's look at monorepos and try to decide if that would be a good decision or not. To make this a monorepo, we would first remove the Git repositories in the individual apps and then set up a single Git repo in the root of this project. This means that anytime code is committed, it's immediately synchronized to all apps within the project. And it gives you a single centralized place to manage all pull requests and issues that come up. A perfect example of a monorepo is Angular itself. For example, you have dozens of different projects within the Angular monorepo such just the router, reactive forms, etcetera. All these packages share the same versioning, so there's never any question about whether or not you're using the right package. So if you have a project that has many different developers contributing or has many different subprojects nested under it, I would highly recommend going the monorepo approach. And there's some good tools out there to help you get the job done right. There's a package called lerna, which is used by the Firebase SDK and many other JavaScript projects. And there's also NX from Narwhal which is an awesome tool for creating monorepos with Angular. But monorepos aren't the right choice for every project. They also have their downsides. A pretty big drawback is a loss in flexibility. It's a lot easier to test and deploy an individual repo than it is to deploy and test an entire mono repo. And when you have small focused projects, you're free to work on them with whatever tooling and best practices that you established. That level of flexibility tends to be very beneficial to small teams and individuals where it might add chaos if you're a large enterprise team with a 100 developers. Because I'm an independent developer and only have a few projects nested Within this workspace, I'm going to go with the multi repo approach. Now let's look at how we can reuse code between these projects by using a shared library with npm. I'm gonna go ahead and create another directory here called shared stuff and then we'll CD into that directory and run npm init to start a new package from scratch. The purpose of this library is to share code between our projects by being installed as a dependency in whatever app needs to use it. The first thing I'll do is create an index TS file inside of here. And then if we look in the package JSON, you'll notice that it has a main property that points to index JS. That's just the main entry point for this package. Then we also want to share typings in this project. So I'm going to set up the types property and have that point to index.d.ts. TypeScript will generate these files for us automatically when we build our code here in a minute. A really common use case is to share interfaces between projects. So I might have a user interface that I want to use in my Angular app, my admin app, and also in my Cloud Functions. If I were to declare this interface in my Angular front end, for example, I wouldn't be able to import it anywhere else. But in a shared package, we can use it in any other JavaScript project. Then we can also export business logic here as well. So I'll just create a function called create ID that returns a random string. So now we need to package our library so it can be consumed by other projects. For a simple use case like this, we can just use TypeScript directly. But for more complex Libraries, you'll probably wanna use something like roll up. To build our library, we need to build script. So we'll go into the package JSON and the build command is just tsc index dot ts and then flagd to also include the typings. Now we can just run npm run build from the command line and that will package up everything with our index. Js and typings. Now we're ready to put our shared library to use. If your company has a lot of shared packages, I would getting an NPM organization set up so you can install everything remotely. But for now, we'll just go ahead and install our shared library locally. We'll start by seeding into our Angular front end, and then we'll run npm install with the path to the folder that contains the shared stuff. Then if we open our package JSON in the Angular app, you'll see that we now have a dependency of the shared stuff library. And we can start using it just like we would with any other npm package. For example, I'll go into the App component here, then I'll import that create ID function that we wrote inside of the library. Then we'll use it to replace the title property on the app component. Then when we serve the app, it generates the title as expected. Now we can go into our Vue app or our functions and follow the exact same process and get the exact same results. Obviously, this is a lot more reliable than trying to copy and paste code between projects. X. But it can also really help with tooling especially when you have shared interfaces. All I have to do is start typing the interface and Versus Code will know to auto import it And we'll also get the IntelliSense autocomplete for all of our shared code. So that's how you create a shared JavaScript library for your project. It can get a lot more complex from there with packaging and things like that. But the final thing that we wanna consider here is that we have this root project directory, but it's currently not under source control. The content in this directory is just configuration stuff, so the Firebase CLI knows where to deploy our apps. But you probably want it under version control as well. So we'll initialize a git repository here, then we'll say git add and git commit. When you create a git repository that has other git repositories nested inside of it, The child repositories will be treated as submodules. I'm gonna go ahead and push this code to GitHub. And if we look at the submodules, you can See that they're just grayed out folders, and we can't actually click inside of them. In this context, we're just using the submodules as placeholders to show what our actual project structure looks like. In other contexts, they can be a pain to deal with. But with our multi repo approach, we're managing each one individually so they can be thought of as their own separate Projects. I'm gonna go ahead and wrap things up there. Hopefully, this video helped you understand how to share code between large JavaScript and or Firebase projects. If you have any questions, leave me a comment below. And if you wanna learn about more advanced concepts, consider upgrading to a pro membership at angularfirebase dotcom. You'll get access to my full courses and a whole bunch of other exclusive content. Thanks for watching, and I'll talk to you soon.
The speaker discusses the difficulty of reuse in large JavaScript projects and recommends using the Angular front end and cloud functions to create multiple apps and functions. The use of monorepos and multiple repos is recommended, and the use of a shared library witherver and a file generated by TypeScript is recommended. Different methods for creating an index TS file and sharing disc depend on the app needed, and shared files are used in other projects, including creating a git repository and using sub variables for project structure. There is also a pro membership for exclusive content and course links are offered.

        [INST]
        You are youtuber called Fireship you make engaging high-intensity and entertaining coding tutorials and tech news. 
        you covers a wide range of topics relevant to programmers, aiming to help them learn and improve their skills quickly.
        
        Given the title of the video : Big JavaScript Projects - Code Sharing 
        and a small summary : The speaker discusses the difficulty of reuse in large JavaScript projects and recommends using the Angular front end and cloud functions to create multiple apps and functions. The use of monorepos and multiple repos is recommended, and the use of a shared library witherver and a file generated by TypeScript is recommended. Different methods for creating an index TS file and sharing disc depend on the app needed, and shared files are used in other projects, including creating a git repository and using sub variables for project structure. There is also a pro membership for exclusive content and course links are offered.
        [/INST]
        
        Generate the video : Code reusability is one of the most important concepts in all of software development. But what often happens is you write some code in one app and then you want to reuse it in a different app down the road, maybe your back end Cloud functions or a different front end app, but it's not very easy to reuse that code because it's tightly coupled to one specific app. In today's video, we'll look at code sharing strategies specifically for large JavaScript projects. If you're new to the channel, like and subscribe and grab the full source code from Angular Firebase dotcom. And I'm also giving away some free swag with this video. All you have to do is leave a comment below, and I'll randomly pick a winner by this weekend. Let's imagine that we have 3 different apps. We have a customer facing Angular app. We used Vue to build an admin app, and then we have a Cloud Functions back end with Node. Js. Our goal with this video is to orchestrate all these projects with Firebase and then also share common business logic and TypeScript interfaces between them. So I just have an empty directory opened up here in Versus Code, and the first thing I'll do is generate our Angular front end by running the ng new command. This just generates a basic Angular app, but the important thing to keep in mind here is that this project has its own package JSON and it also has its own dedicated Git repository. Now to add some complexity, I'll also generate a Vue app with the Vue CLI. And just like Angular, it has its own package JSON and its own Git repo. Then we'll give our app a back end by initializing Firebase. And I'm going to select functions and hosting as the Firebase features. The functions directory is also a Node. Js project, so it has its own package JSON. And then it doesn't have a Git repository by default, but you can initialize 1 in there as well. So now we have Firebase initialized in this parent directory, and we can orchestrate the deployments for our front end apps and our functions. I have an entire video on multisite hosting, so make sure to check that out. But what we can do in this Firebase JSON file is set up multiple hosting targets so we can deploy our Angular app to 1 l and our view app to a different URL but have them share the same Firebase project. At this point, we have a project with multiple apps and we have a big decision to make. Do we structure this as a monorepo or maintain multiple repos? 1st, let's look at monorepos and try to decide if that would be a good decision or not. To make this a monorepo, we would first remove the Git repositories in the individual apps and then set up a single Git repo in the root of this project. This means that anytime code is committed, it's immediately synchronized to all apps within the project. And it gives you a single centralized place to manage all pull requests and issues that come up. A perfect example of a monorepo is Angular itself. For example, you have dozens of different projects within the Angular monorepo such just the router, reactive forms, etcetera. All these packages share the same versioning, so there's never any question about whether or not you're using the right package. So if you have a project that has many different developers contributing or has many different subprojects nested under it, I would highly recommend going the monorepo approach. And there's some good tools out there to help you get the job done right. There's a package called lerna, which is used by the Firebase SDK and many other JavaScript projects. And there's also NX from Narwhal which is an awesome tool for creating monorepos with Angular. But monorepos aren't the right choice for every project. They also have their downsides. A pretty big drawback is a loss in flexibility. It's a lot easier to test and deploy an individual repo than it is to deploy and test an entire mono repo. And when you have small focused projects, you're free to work on them with whatever tooling and best practices that you established. That level of flexibility tends to be very beneficial to small teams and individuals where it might add chaos if you're a large enterprise team with a 100 developers. Because I'm an independent developer and only have a few projects nested Within this workspace, I'm going to go with the multi repo approach. Now let's look at how we can reuse code between these projects by using a shared library with npm. I'm gonna go ahead and create another directory here called shared stuff and then we'll CD into that directory and run npm init to start a new package from scratch. The purpose of this library is to share code between our projects by being installed as a dependency in whatever app needs to use it. The first thing I'll do is create an index TS file inside of here. And then if we look in the package JSON, you'll notice that it has a main property that points to index JS. That's just the main entry point for this package. Then we also want to share typings in this project. So I'm going to set up the types property and have that point to index.d.ts. TypeScript will generate these files for us automatically when we build our code here in a minute. A really common use case is to share interfaces between projects. So I might have a user interface that I want to use in my Angular app, my admin app, and also in my Cloud Functions. If I were to declare this interface in my Angular front end, for example, I wouldn't be able to import it anywhere else. But in a shared package, we can use it in any other JavaScript project. Then we can also export business logic here as well. So I'll just create a function called create ID that returns a random string. So now we need to package our library so it can be consumed by other projects. For a simple use case like this, we can just use TypeScript directly. But for more complex Libraries, you'll probably wanna use something like roll up. To build our library, we need to build script. So we'll go into the package JSON and the build command is just tsc index dot ts and then flagd to also include the typings. Now we can just run npm run build from the command line and that will package up everything with our index. Js and typings. Now we're ready to put our shared library to use. If your company has a lot of shared packages, I would getting an NPM organization set up so you can install everything remotely. But for now, we'll just go ahead and install our shared library locally. We'll start by seeding into our Angular front end, and then we'll run npm install with the path to the folder that contains the shared stuff. Then if we open our package JSON in the Angular app, you'll see that we now have a dependency of the shared stuff library. And we can start using it just like we would with any other npm package. For example, I'll go into the App component here, then I'll import that create ID function that we wrote inside of the library. Then we'll use it to replace the title property on the app component. Then when we serve the app, it generates the title as expected. Now we can go into our Vue app or our functions and follow the exact same process and get the exact same results. Obviously, this is a lot more reliable than trying to copy and paste code between projects. X. But it can also really help with tooling especially when you have shared interfaces. All I have to do is start typing the interface and Versus Code will know to auto import it And we'll also get the IntelliSense autocomplete for all of our shared code. So that's how you create a shared JavaScript library for your project. It can get a lot more complex from there with packaging and things like that. But the final thing that we wanna consider here is that we have this root project directory, but it's currently not under source control. The content in this directory is just configuration stuff, so the Firebase CLI knows where to deploy our apps. But you probably want it under version control as well. So we'll initialize a git repository here, then we'll say git add and git commit. When you create a git repository that has other git repositories nested inside of it, The child repositories will be treated as submodules. I'm gonna go ahead and push this code to GitHub. And if we look at the submodules, you can See that they're just grayed out folders, and we can't actually click inside of them. In this context, we're just using the submodules as placeholders to show what our actual project structure looks like. In other contexts, they can be a pain to deal with. But with our multi repo approach, we're managing each one individually so they can be thought of as their own separate Projects. I'm gonna go ahead and wrap things up there. Hopefully, this video helped you understand how to share code between large JavaScript and or Firebase projects. If you have any questions, leave me a comment below. And if you wanna learn about more advanced concepts, consider upgrading to a pro membership at angularfirebase dotcom. You'll get access to my full courses and a whole bunch of other exclusive content. Thanks for watching, and I'll talk to you soon.
        