OK, a lot of stuff to figure out here.
Let's get to it.
I'm going to first begin inside of my code editor inside of here.
I'm going to find out unpackaged path plug in file that I gave you just a moment to go inside of here
is a function declaration that returns an object.
This object is a plugin that works inside of its built.
Now we're learning about making plug ins for E build.
And you might have not even heard of s build before this course.
So you might think, hey, this is going to useless knowledge.
Don't sweat.
It turns out that all these different plug ins work very similarly in the world of Web hack as well.
So all the knowledge you're picking up right now, you can eventually apply to other bundling frameworks.
Trust me, this is pretty valuable stuff.
All right, so again, we've got this object being returned, it has two different properties, a name
property and a set up function, the name property is really just for debugging purposes.
You might eventually have several different plug ins working inside of your project, and you might
need to debug how they are all interacting with each other.
And during that process, just to make identifying these different plug ins a little bit easier.
This name property will be printed out by its built.
So beyond that, we don't really care about the name property quite so much.
The other property, however, the setup function, that is what we very much care about, this set
of function is going to be called automatically by its build with a single argument and we call it build.
This build argument right here represents the bundling process, the entire process of finding some
file, loading it up, parsing it, transpiring it, and then joining a bunch of different files together
so we can kind of interact or interfere or override certain parts that bundling process by working with
this build argument.
The two primary ways in which we interact with this build process is by attaching event listeners to
listen to the unresolved and onload events.
I'm going to describe exactly what these two listeners are all about in just a moment.
But first, let me tell you a little bit more about what this plugin generally does.
All right, quick diagram.
So inside this log-in, I have hardcoded two different kind of imaginary files, and this is why we
did not have to enter in any text manually to that text area.
In the last video when we tried running The Bundler, the two hardcoded files inside of here are an
indexed JS file that contains this code and a message just file that contains that code.
Not exactly hello there, but rather close.
You can very easily see those two files by scrolling down towards the bottom of this plugin, so here
is that imaginary index tags and here is the message as file.
These are currently hard coded into the plugin, we are going to eventually delete these, I only added
them in so we can see some immediate output and really understand what the plugin is doing for us.
The really quickly thinking back to when we were working directly with Westpac just a little bit ago,
remember, we ran Westpac on these two different files and we saw that Westpac kind of wrapped one inside
of a function.
It kind of stored that function inside of an object.
It defined some kind of imaginary Westpac require function that was used to kind of join these two files
together intelligently.
Yes, build works slightly differently, yes, build is a little bit more intelligent when it comes
to stripping out unused code and in general it produces bundles that are a little bit smaller or sometimes
a lot smaller than the bundles that are created by Westpac.
So we can see the output.
Of build's bundling process right here on the screen, this right here is 100 percent working good code
that very much accurately describes what we are trying to do when we bundle these two files together.
In other words, if you look at this code right here and imagine how we would expect this to actually
execute well, all we are really trying to do is define a string of hello there and then log it.
And without a doubt, that is what the output of Eskild build actually does here.
But to accomplish this without defining all those extra helper functions and all that extra stuff that
Westpac did, you'll notice right away that Eskild build is a little bit more streamlined than Webberley.
At the end of the day, all these different bundlers work slightly differently, but as long as they
spit out code that actually works, that is, of course, what we really care about.
OK, so now I want to tell you just a little bit about those two event listeners I mentioned just a
moment ago.
So unresolved and onload, what are these two things all about and what are we going to eventually use
them for, though?
Another quick diagram.
So as we just saw, we've got index dogs and message dogs.
I also want to remind you very quickly that inside of our index TSX file, we had specified an entry
point right here of Index JASE'S.
That means that we want our index dogs file to be the first one to be bundled inside of our application
so we can kind of imagine what is going on behind the scenes with us build inside this diagram.
We essentially told us build that we wanted it to bundle the index, not just file, we did not actually
provide the contents of that file in any way, shape or form directly.
When we started up the bundling process, we just said, please bundle the index file.
Yes, Bill then started up a bundling process inside the browser, it then went through the following
series of steps.
The first thing that it did, it tried to figure out or determine what the path was to get to the index
JS file, in other words, where it is stored.
We refer to this process of figuring out where this file is stored as the unresolved step, that is
what this unresolved function back here.
Does this function right here that we defined essentially overrides or kind of hijacks us, builds a
natural process of trying to figure out where the file is stored or what the actual path to that file
is.
Once that unresolved step was executed, Eskild then took that path that was generated during that step.
That's essentially what we're returning right there and it used that path to attempt to load that file
up.
Whenever Eskild attempts to load up a file, we refer to that as the onload step.
And so that is the other function that was defined inside of here.
It is right here.
Build dot onload by defining this listener right here.
Once again, we have kind of hijacked or overridden.
Yes.
Builds natural way of loading up a file, which is to just read it directly off a file system.
Instead, we said, you know what, you just build, don't sweat it.
Don't try to load up this file off the file system.
We're just going to return an object for you immediately that contains the contents of that file you
were trying to load.
So inside this onload function, we're essentially saying if Eskild is attempting to load the index
JS file, don't let it do its normal thing.
Don't let it try to load up something on the file system instead.
Look, we loaded it for you.
Here it is right here.
Here's the contents of that file that you were looking for.
So we overrode that piece of functionality with our plugin.
Once we returned that file to build through that object that we were just looking at its build then
attempted to pass that file and when it passed it, it tried to find any import statements, any requires,
any exports or anything like that, if it found anything like that inside the index JS file.
And it definitely did.
We've got import message from message right there.
Then it's billed is going to repeat these two steps up here once again for the file that we were trying
to import.
So it's build is going to take that important statement that it found for the messages file and it's
going to once again run the unresolved step, which again is how it is going to try to figure out where
that file exists or what the path to it is.
That means that we would run the unresolved function right here a second time.
This time around, the expectation would be that we return some kind of object describing where that
message, not Jase's file is.
Want to return that object, yes, build, then use that object to attempt to actually load the file
up.
So it said, OK, here's a file, I'm going to try to load it up.
As it tried to load that file up, remember, we referred to that as the onload step and once again
this time we intercepted that OnLoad call.
When we intercepted the call, we said, hey, you know what, if you're trying to find anything besides
the index, just file.
Here it is.
We've got it for you.
It's right here.
Don't try to go to the file system.
Don't try to access the hard drive because that would result in an error.
Instead, here's the code you're looking for.
He has built this is the contents of the messages file.
Just trust us.
This is what it is.
So Eskild took that contents right there and used it to complete the bundling process.
OK, so that's a deep dive on what is going on behind the scenes with Eskild and how that plug in kind
of interfaces with it.
So, again, the really critical things here to understand is that there is an unresolved step that
is used to figure out what the actual path is to a particular file inside of a plug in.
If you and I define an unresolved function, we have the ability to override that, assuming we have
the ability to override where Eskild tries to find that file.
And that's exactly what we're doing.
There's also an onload step that onload step is what is used to actually load up a file off the file
system.
And once again, if we define that onload callback inside of a plugin, we're going to override build's
natural process of trying to access the file system.
Both these steps are on resolve and onload are totally critical for us to implement and make sure that
we handle inside of our app, because if we just allow it's built to try to take care of the resolve
or the onload step, we're going to very quickly get an error message because it's build is going to
try to access the file system.
I can prove that to you very easily.
Back inside this plug in, I'm going to find that build on resolve right there.
I'm just going to comment it out.
I'll then save this file.
I'm going to go back to the browser, refresh the page and click on submit and sure enough, very quickly,
we get an error message and it definitely looks kind of like it's something related to a sorry, but
we can't read a directory.
Don't even try.
So only by implementing these two functions on resolve and onload and overriding build's natural behavior
are going to be able to run or create a bundle inside the browser.
All right, so I think we got a better idea of what's going on here, but the one exception, we didn't
really discuss what this filter thing is all about or what the namespace thing is all about.
So let's take a pause right here.
We're going to do a little bit more investigation into what's going on here and then eventually start
to tweak this code to actually work and allow us to import any kind of arbitrary module into our project.