All right, let's start knocking these items down one by one, so we're going to go through all three
different packages, update some packages on files and specify exactly what files we want to send off
to 9pm when we publish these things, like we'll first begin inside of my package JSON file for our
Seelie package inside of here, anywhere inside this file, we will add in a new section of files.
And inside of here, the only thing we really want to send off to NPM will be that dist directory so
we can put in dist like so.
OK, let's go over to local API, repeat the same process here is local API.
I will add in philes.
And we will add in once again our director.
And then finally on to local clients.
We will add in philes.
And then in this case, we do not have a direct directory.
Instead, whenever 9pm or whenever ReachOut builds our project, the output is put inside this build
directory.
So we're going to say that we want to publish everything inside the build folder.
OK, so that's it.
So that's another step, Don.
Let's now go through and audit all of our different dependencies and dev dependencies, we've already
set up two of our packages very well for this already, but we do have to make a couple of changes to
our ReachOut project.
So let's just go to this very quickly.
First, inside of my Seelie package, JSON file.
I definitely need, commander, whenever we are running on a user's machine and we definitely need local
API whenever a user is running our application as well.
However, our type file and the type scripts runtime are not skimming, not the runtime, but the typescript
library itself.
Only needed during development when we are trying to develop or build our project, so those are definitely
good candidates for dev dependencies.
But no change is required.
Let's move on to local AP.
OK, inside of local API, I'll first take a look at dependencies we've got course, we did not actually
make use, of course, but we might actually need it at some point in time.
I'm going to leave that inside of your for now.
We definitely need to express and we definitely need local clients.
But do we need HTTP proxy middleware?
And this is where the distinction between dependencies and dev dependencies starts to get really weird.
So HTTP proxy middleware is a package that is technically only used by us during development.
That's the only time that we actually set up a proxy.
However, remember inside of our source index stats file.
Inside of our local project, no matter what, no matter whether we are running this package in a development
or production mode, in all scenarios, we always import this library no matter what.
So because we've written out this import statement in this way, that means that we have to include
it when we start to install all the stuff on the user's machine.
If we mark this as a development only dependency, then as soon as we start to run this code on the
user's machine node is going to see an import statement for approximately where it's not going to find
that package installed.
Air will be thrown very quickly.
So it's not always a question strictly of am I using this package during development or not sometimes
because of the way we have written code out.
We still have to include packages as a dependency, even if technically we're only using them effectively
during the development process.
So, again, no changes are needed here.
OK, so now onto local client.
So I'm going to find the package, some file inside of my local client directory now inside of you.
If we take a look at dependencies right away, we're going to see that there are a tremendous number
of dependencies that probably are development dependencies such as all these type definition files and
all these different testing library things as well.
But here's the real tricky thing about our REACT application.
Remember that whenever a user installs are Seelie, they're not going to be running react up at all.
They're not going to be bundling our local client or anything like that.
The only purpose of local client, once it has been installed on the user's machine is to serve out
some of the different files and folders inside of our build directory.
That is it.
So we don't actually need any dependencies at all when we install a local client onto a user's machine.
We can actually take this entire dependency section and just relabel it to all be the dependencies instead.
Now, this might be a little bit tricky if you're looking at this and saying there's no way that's going
to work, hey, of course, let's actually do that deploy eventually run it on our machine.
And I think it will come back and say, yeah, it turns out we actually don't need any of these at all
because all we really care about are the built projectiles.
And the same is not true of these other projects, just to be clear, because, remember, ReachOut
is doing a bundling process.
It is taking all these dependencies, such as react, react, redux and so on, and including them inside
of the built project files.
Whereas whenever we do a build of, say, our Arkley, we are only putting inside of the transport all
the files.
And we are still relying upon going into our node modules directory and finding the relevant dependencies
whenever we require them into those JavaScript files.
That is the big difference here.
OK, so this video is running just a little bit long, but I do want to take care of the next step because
it's very fast and easy.
We have to go through all of our different packages and just get them to be publicly accessible.
So for that, we're going to start off first with our Seelie.
Here's a Seelie packages on file and anywhere inside of here.
We're going to add in that published config.
I'm going to copy that block.
I'll go over to my local AP package, JSON file and paste the same thing in.
And then finally, inside of my local client package, Jason File, I'm going to find the existing private
true inside there.
I'm going to delete that and replace it with the published config access public.
OK, so that's it.
Let's take a pause right here and then continue on in just a moment.