To help illustrate why this approach right here is not going to work in the long run, I've created
another little test package for us to try out.
So back inside my browser, I'm going to go to unpackaged dotcom slash medium test EKG.
So this is a package that I have also published on NPM that has two different files inside of it, we're
currently looking at the index tax file and notice how this file requires in another file called the
Utils File.
In reality, to get at that file, we could make a request to the same URL, but instead of indexed,
we would want to go to utils.
So if I make a request to that, I see the contents of that utils file.
So this is what we want to load up inside of our application.
If we were trying to bundle, trying to bundle in the medium test package.
But as you can guess, it is not going to work as expected.
Let's go back over to our plug in.
We're going to first get started by going down to unload and inside of our hardcoded indexed JS file,
rather than trying to require in a tiny test package.
I'm going to instead try to require in medium test package.
I'll then save that.
Go back over, refresh the app.
And I just want you to know that this is going to result in a little bit more requests than you might
expect, so don't sweat it too much if that happens.
All right, I'm going to click on Submit.
And right away, you're going to see a rather large number of requests being made.
So what's going on here?
Well, it doesn't really take a look at all these different logs.
We're getting back and trying to figure out what happened.
It's going to scroll up a little bit.
We're going to see a lot of different kinds of logs coming from on resolve and onload.
It looks like the first set right there of on resolving unload or for index tags to find.
The second one is an unresolved for medium test package.
Then unload the unload is for medium test, which is definitely good.
We want to load up that file.
So we are attempting to make a request to medium test package, which would give us this indexed JS
file.
Remember, we are going to give the contents of this file off to its build.
Its build is then going to pass the contents of this file and attempt to find any required statements
inside of here or any import statements in this case.
It is going to find a require it seems to require for dot utils.
Well, then move on to the next one on resolve, this is when its build is going to try to figure out
a path to load up that utils file and notice very helpfully, we are told, who is attempting to import
that file.
That's going to become relevant in just a moment.
But unfortunately, right now we are taking that utils and we are generating a path out of it and a
very naive fashion.
Once again, we're just joining it into that URL.
So the result is that we return a path that looks like that unpackaged dotcom slash dot utils, so that
is the file that we are attempting to load if you try to make a request to that path.
You're going to actually load up a totally different module, a module called utils, so clearly that
unpackaged com slash dot slash utils that just plain gives us the wrong module.
So these URLs that we are generating in this new fashion, they're not going to work out in the long
run.
This is a problem that's going to come up any time that we are trying to import or require in a module
that imports another file.
So exactly like this case right here.
So all this really means is that we need to come up with this strategy for generating the URL to fetch
a path from in a much more clever fashion than what we are doing right now.
We cannot just take our exact path.
Instead, we need to figure out what file was trying to import this.
So in other words, who is trying to import utils?
And we need to resolve that URL relative to this current URL.
So in other words, if we are at this URL and we are trying to require in slash utils, that means we
want essentially in the same directory.
So like utils, that is the path we want.
That's the next big change we need to make.
Let's figure out how to tackle this in just a moment.