All right, my friends, let's try updating this plugin and allow it to fetch a module live off of Unpackaged,
the first thing we're going to do is make a little update or two to the unresolved function.
Remember, unresolved is going to be called whenever Eskild is trying to figure out a path to a particular
module.
We currently have a consulate inside of here.
The consulate is currently staying on Resul, I'm going to just fix that up really quickly.
There we go, unresolved and then printing out the arguments dysfunction.
Let's go back over to our browser really quick and see what arguments we get whenever Eskild is attempting
to figure out a path to a module back inside of my browser, I'll refresh, submit, still get there
to define what?
I'm going to take a look at the console log for unresolved.
It looks like the very first time unresolved gets called.
We've got arguments of importer namespace Pappe and Resolve Directory.
This is the console log for on result for the index as file.
We don't really care about that quite so much right now.
Instead, we really care about the second console log.
This is the unresolved call for tiny test package.
So in this case, we are told which file is attempting to import this package, the namespace of that
file and then the current path or what we think of the path to this file is so right now it's build
things.
The path to it is tiny test package.
That's not really a valid path.
We can only use that for anything.
That's not a URL that we can fetch some resource from.
It's not a path to some file on the file system.
So you and I have to read in this path right here and somehow convert it into an actual path that can
be fetched at some point in time.
So our ultimate goal inside of unresolved is to detect whenever we are trying to get the path for tiny
test a package, and if we are, rather than just returning back the current path that was provided
to our resolve, we want to instead provide a path to unpackaged dotcom, tiny test package.
That's what we need to do inside of here.
So right now, we're going to take a very naive approach.
We're going to say if our path.
Is indexed, James.
Let's just keep doing what we're doing, so I'm going to cut and paste the return statement inside their.
And then going to put in and else if and I'll say our exact path is tiny test package and we need to
do something slightly different.
So in this case, I'm going to return.
A path to and we want to put inside of here the unpackaged path to our module.
So that would be the unpackaged dotcom, so just to be precise, unpackaged dotcom, a tiny test package,
at one point zero indexed -- can take that full URL right there.
And pasted in like so.
I'm also going to apply a namespace of a right now as well.
And they're going to save this.
OK, so again, this is still a very naive approach, but it's going to help us just kind of gently
refactor this code into over time and making sure that we can eventually get some path for any arbitrary
module.
So not going to save this.
Go back to the browser, refresh again, click on submit.
And now, while we still get an air, but take a look at the air that we have now, this air now says
file could not be loaded and we are attempting to load that file right there.
So this here means that we are still falling into our onload function at some point in time, but we
don't have any case inside of here to handle loading up something besides the index --.
So we now need to somehow make a request off to unpackaged or essentially whatever the args half property
is, we need to somehow fetch the contents of the file at that URL.
Let me just clarify what I mean by that.
Let's go back inside the browser.
We're going to find the OnLoad console log.
You'll see that OnLoad console log now has the path to the file that this OnLoad is trying to fetch
right now are onload doesn't have any case inside of it for trying to deal with a request to fetch that
file.
So all we have to do is add in some code to make a network request to that URL.
That's the contents of that file and then return it from this onload in just the same way that we're
doing for the index, such as file.
So for this, we're going to make use of Axios, we're going to install Axios into our project if we
ever try to fetch a file with a path besides index stocks and we'll make a request with Axios to our
exact path.
And that should give us back the contents of whatever file is at that URL right there.
I'm going to first begin by going over to my terminal.
I'm going to open up a second window still inside my project and do a very quick NPM install Axios.
Once that is installed, I'm going to let it do its thing back inside of my plug and file at the very
top, I will import Axios from Axios.
Then back down after the statement.
I'm going to add in.
A concert data.
Is a wait Axios docket, and I'm going to get whatever is at our exact path.
Remember, we just on the council log our exact path is that you are right there.
We're going to get that path.
And hopefully data now should contain whatever the text content is of that file.
Let's just do a log of that data just to make sure we're actually fetching the code we're looking for.
So I'll save that you flip back over to another simit.
And there's the council log that we are now definitely loading up the contents of a file directly from
Unpackaged.
Now, the last thing we have to do is make sure that we take that data, that we have fetched the contents
of that file and return an object from OnLoad that looks just like this right here.
This object is essentially, remember, going to tell us build.
Hey, don't worry.
Don't try to access the file system.
We loaded up the file for you.
Here's the contents of that file.
So I'm going to return.
An object, I'm going to say apply a loader of gas and remember, that just means it's billed is going
to understand it might have to pass some gas inside that file and then the contents will be data.
OK, let's save this.
Go back over, refresh and do another test, eh?
There we go.
You'll notice that there's a lot more stuff going on here than we had before.
That is because we are now mixing and matching.
Yes, to me, yes.
Modules and common modules.
That's why there's so much code inside of here.
You'll notice that there are a couple of functions like, say, common gas and stuff like that.
Again, the tiny module that I just provided to you is making use of common gas.
But the index JS file that is hard coded inside of our plug and right now is making use of its modules.
I bet you if we actually convert them both to be the same module type, we might see the actual total
bundle size start to go down.
Let's try that out really quickly.
Back inside my editor, I'm going to update the hardcoded indexed JS file to instead be constant message
is require.
Tiny test package.
Let's save that, let's do a refresh submit.
All right, I guess a little bit less, definitely still more than we were only using Eskild, but I
think this is definitely good progress.
We have now really proved that we can have some amount of code that is provided by our user like you
or me writing inside of a code editor.
Not quite just yet, but we're very close to that and we've proved that we can somehow live.
That's a file off of unpackaged dot com and include it inside of some bundle.
So this is definitely good progress.
But of course, right now we've got some code that's just, well, still a little bit hard coded.
We need to make sure that we generate a year like this on the fly rather than always just hard coding
in some kind of like our exact path check.
So still a little bit more progress.
Let's continue on in the next video.