In this video, we're going to take a look at one more breaking case with our current path resolution
algorithm to get started inside my unresolved function.
I've left a comment at the bottom of that function for quite a while now.
Don't really need this comment anymore.
I'm going to clean it up very quickly.
After that, I'm going to find the OnLoad function.
Remember, inside of here, we have a hard coded index file inside.
There we are attempting to require in medium test package.
I've published yet another package off to NPM.
We're going to try to require in this third package and attempt to include it inside of our bundle.
So I'm going to find the required medium test package right here and update it to nested test package.
So this new package that we're going to try to bundle up has a slightly different file and folder structure
that's going to cause some problems with our current path resolution algorithm.
Let's say this file now go back to the browser.
I'm going to refresh Zimet, and once again, we're going to start to see some big error messages,
so we need to figure out what's going wrong now.
Why is our path resolution failing?
Well, to really understand this, I want to first take a look at some of the different files and folders
that are inside of this new nested test package.
So inside this diagram, I've got the file and folder structure of medium test package.
On the left hand side, there was one folder that had index tags and utils dogs inside of it.
So when we were trying to bundle this file and folder structure, everything worked as expected.
But now we are trying to bundle up a slightly different file and folder structure, this nested test
package as an Sarsae folder inside of it.
It is the presence of this SIRC folder that is causing us problems now.
So I'm going to show you a couple of diagrams and help you understand why the presence of that folder
is giving us trouble.
Inside of SIRC is the index dog's file, which is what we are ultimately trying to require.
There's also a helper's folder with the utils dogs file inside there as well.
So why is the SIRC folder giving us trouble?
Well, let's take a look at a diagram once again.
This same structure, we've seen this once before, we're going to walk through and really imagine the
entire resolution algorithm file by file.
So, again, we start off with our index dogs while we go through unresolved, unload the load up the
contents of that file, kind of it's all hardcoded right now.
We passed the contents of that file after we build us build passes the contents it sees that we are
trying to require in nested test package.
It's built then creates an object that looks like this right here and provides it to work on Resul function.
So our path is nested test package and the importer is index.
As usual, you can see that on the log right here.
So path massive tax package importers, index dogs.
You and I then take that path, we realize that we are attempting to to import some kind of module off
of NPM or some kind of NPE module.
So we joined the module name together with unpackaged dotcom, and we come up with a path that looks
like this right here.
So an object that looks like this is provided to our onload function.
And this is the basis.
This is what we have to go on for, fetching this file or this package off of NPM or trying to match
the contents of that file.
Really?
Again, we can see a consultive for that very easily right here.
So we go and fetch that file, we go and fetch that index file or essentially the root file of this
package.
Now, quick reminder, whenever we go to unpackaged dotcom.
So unpackaged dotcom flash, say, nested test EKG, if I just navigate directly to that path right
there on package, dot com is going to automatically redirect me to the main file of this package.
In this case, the main file is SIRC indexed.
That is the main file.
That is where we get redirected to.
Just keep that in your mind for just a moment.
So we make a request to that you are all right there, we get the contents of that file and during that
process, remember, the actual file is not at that URL.
It's actually at SIRC Index.
Regardless, we load up the file, we return the contents.
Yes, bill passes it and sees once again that we are trying to require in some other file, in this
case, the requires for helpers utils.
So an object that looks like this right here is provided to our unresolved function, again, as usual,
we can see that along very easily.
Here it is right here, the path is Helper's utils and the importer is very clearly nested test package.
But here's the problem.
The importer is not actually nested test package.
The actual importer is nested test package.
SIRC index, James.
So we have an incorrect importer, the importer is not correct, it thinks that we are getting the file
from here or the index as file is the one that is importing utils.
That is not correct.
It is actually nested test package SIRC.
Index dot deez.
Regardless, we then apply our path resolution algorithm, which essentially just says, take this importer.
Join on that path, turn into your URL and try to go and fetch it so you and I are generating a path
right now that looks like this.
We take the importer, which is just nested test package, and then we add on the dot helper's utils
and we end up with the URL like this right here.
Our file is not at that URL.
If I tried to navigate to that URL.
Inside my browser's.
Doesn't exist.
Instead, what we really want to do is generate, if you like, this, something that includes where
we actually found that root file, where we actually found that indexed JS file.
So we need to somehow get that SIRC inside there.
That's what we really need to do.
Now, you might think, OK, Stephen, whatever.
Let's just go ahead and hard code in.
Back up here where we've got our special case, let's just hard coding like SC, no, that's not going
to work because remember, we're not always walking into some SC directory.
You might actually be like a live folder or a disk folder or something like that.
We don't really know what the name of this file or that folder is ahead of time.
So we really need to get all that more clever here.
We need to figure out some better way of resolving this path, really considering where we found that
initial file inside the package.
With all this in mind, I've come up with a slightly better approach here, something to kind of explain
the logic that we really need to apply.
Let's take a look at one or two more very quick diagrams.
OK, so here's what we really need to encode inside of our path resolution algorithm.
Whenever we are fetching the main file of a package, so in other words, if we ever require statement
for something like Axios or require a statement for something like react or react or something like
that, we are attempting to fetch the main file of a package.
So that would be like when we are attempting to.
Find this file, if we are attempting to find nested test package, that means that we are trying to
get the main file of a package.
If that's the case and we need to make a request to unpackaged dot com slash plus the package name.
However, if we are attempting to match any other file inside that package, so any other file besides
that main initial file of a package, then our resolution algorithm is going to be slightly different.
It needs to be unpackaged dotcom slash, plus the directory that the last file was found in, plus the
require statement for this file.
Now, these little steps right here might not be super clear.
So let me show you a more practical example.
So at some point in time, we had to require statement for nested test package, that is the initial
import or the initial required for this package.
So we are going to apply this first rule to it.
We would find this URL by making request you unpackaged dot com slash plus nested test package.
We would end up with URLs like this right here.
We would make a request that URL and behind the scenes Unpackaged would redirect us to where you URL
that actually looks like this.
So nested test package, Sarsae, that is the directory that we found indexed JS file in, when we fetch
that index file, then inside there is a required statement for that Helper's utility JS file.
That is when we are going to start to apply the second rule, we are now attempting to find some other
file inside that package.
In this case, it is the utils or helper's.
Utils, not just file.
Now we're going to apply this different rule because we are not trying to affect the main file of a
package.
So in this case, we would generate our URL by doing unpackaged dotcom plus wherever we got the last
file from the directory of the last fetched file or the one that is trying to import this, the path
to the last fetched file.
Is that right there, that is the directory, the last fetched file, so we need to somehow get access
to that and we're going to join that together with the require statement that we are currently trying
to resolve.
So pretty much that string right there.
So if we join these three things together, we end up with you.
All of this right here.
We end up with unpackaged dotcom nested test package, Sarsae Helper's utils dojos, which is the correct
URL.
We try to visit that inside of our browser.
We do, in fact, load up the correct file, so that's it, this is kind of like the final version of
our algorithm.
This is what we really need to do.
The big stretch here is making sure that we can somehow communicate this last fetched directory to the
next file that we are attempting to fetch.
That is the hard part.
We need to essentially, whenever we get the file or any subsequent file out of a package, we need
to find where we got that file from and somehow provide it to the resolution of the next require statement.
That is the challenge here.
Fortunately, this is going to be pretty easy because this is a feature that is built into built or
there's kind of something inside of SBL that's going to make this easy.
But it's understanding what we have to do here that makes this really challenging.
Hopefully now you can start to understand why if we just wrote out all the code for this, it would
have just been like, OK, no idea what's going on here.
You really have to go through all this stuff step by step, see the kind of failing cases and fix the
code up step by step.
So now that we've got a better idea of what's going on, implementation in the next video.