We've now seen that if we could somehow download that source code or that raw archive into the browser
when we were doing this bundling, we could then get all the source code required for react.
We could then in theory, somehow provide that source code off to us build and it could use it during
the bundling process.
But as I mentioned twice now, unfortunately, we're not going to build a reach out directly to NPM
to download those archives, all for a very simple reason.
I'm back inside my browser at localhost three thousand.
I'm going to open up my console while on the network tab.
Remember, you can press escape to open up that console and I'm going to try to directly download that
same archive that we downloaded in the last video by using some JavaScript code inside of here.
So to do so, I'm going to put in fetch paste in that link like so and run it.
So in theory, that should download that archive.
We are going to have an archive.
So we then have to figure out how to extract the contents, but at least we would have all the source
code required for react.
But when I run that, I get back in air very quickly.
And this area here is exactly why we cannot reach out directly to NPM when trying to fetch these dependencies.
Whenever you are inside the browser at some URL, such as localhost three thousand, if you make any
JavaScript based request with something like fetch or axios or anything similar, your browser is going
to send along some information in that request describing what the current URL of the browser is in
this case.
Localhost three thousand.
Unfortunately, the NPM registry is configured to reject any download request if a user is at some URL,
probably besides NPM, JAG Registry JAG.
So long story short, due to a cause error, we cannot reach directly out to the registry to download
the source code for all these different packages.
So we're going to try to figure out some other solution.
We could, in theory, set up a kind of proxy to handle downloading these things, if you're familiar
with that at all.
But we're going to take just a little bit easier solution.
Instead of a new browser tab, I'm going to do a Google search for u n g.
Well, then find the first link right here, unpackaged dotcom, this is a public CDN that we can use
for free, but it contains all the source code that is hosted on NPM.
So we can use this website to essentially get direct access to that exact same NPM registry.
Are we're going to do it by going through unpackaged rather than trying to reach out to that registry
registry directly?
In order to download something like react or get the source good for react, here's what we would do.
We would try to make a request to unpackaged dotcom react.
That's it.
If we make a request to this URL or react, then we're going to be automatically directed to the current
version of REACT.
And more importantly, we're going to be directed to the file that is listed inside of that packages
package, JSON file.
So look at that is the exact same source code that we just saw when we downloaded react manually onto
our machines.
So now things are starting to come together, hopefully now.
We're starting to understand that whenever Eskild sees an import statement like import react from react,
we're going to intercept that request to figure out what the path is on the local filesystem.
To find that dependency dependancy, we're going to jump in, intercept Eskild and say we're going to
figure out what that path is then rather than reaching out to the NPM registry.
All we have to do is make a request to unpackaged dotcom, the name of the package we're looking for,
which in this case is react unpackaged, is not only going to redirect us to the current version of
this package, whatever the latest version is, but it's also going to redirect us to whatever the main
file or the entry point of that package is as well.
So we could take this link right here.
And hand that link as though we're going to get back from Unpackaged, can have that link directly off
to build and say that's it, that's where you can find the source code for react.
Now, there are a couple of little steps inside of here that I'm kind of skipping over that will run
into in due time, but this is the general idea.
This is how we're going to generally do some bundling inside the browser.
You and I are going to write a plug in to intercept all the different path resolutions.
We're going to make use of Unpackaged to figure out what the current version is and what the main file
of that packages.
And we're going to pass that part back into build.
So a lot of code for us to write.
A lot of stuff going on here.
Let's take a pause and get started in just a moment.