-
-
Notifications
You must be signed in to change notification settings - Fork 3.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Updated output-management.md #1344
Conversation
Rewrite of this guide as a logical follow up of the `Asset Management` guide. (Will add more advanced example with multiple assets later)
@skipjack I've rewritten this part of the guide, would love your feedback! I'm thinking of adding one more advanced example with multiple other assets, just to illustrate how that would work. The original guide had something about multiple outputs, but that seems to be covered by the |
Travis seems to check for a I removed that section but I don't know how to update the link checker, help would be appreciated! |
Fixed broken link
Will do as soon as I have a bit more time. Saturday at the latest, if not sooner.
This is due to another page linking to that anchor. If you look closely at the error in the log it should tell you which page (although you'll see it as an |
@skipjack couple of newbee questions:
Thanks! |
@skipjack Added section about cleaning up the |
Just commit any other changes to the same
It looks like you fixed this by removing the section linking to it from the concepts page. |
content/guides/output-management.md
Outdated
|
||
First let's take a look at where you might stand without these plugins: | ||
So far we've manually included all our assets in our `index.html` file, but as your application grows and once you start [using hashes in filenames](/guides/caching) and outputting [multiple bundles](/guides/code-splitting-libraries), it will be difficult to keep managing your `index.html` file manually. However, there's no need to fear as a few plugins exist that will make this process much easier to manage. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The multiple bundles
link should just point to /guides/code-splitting
.
content/guides/output-management.md
Outdated
|
||
__index.html__ | ||
## Preparation ## |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you remove the trailing ##
on this title and the others for consistency with the rest of the markdown files. I didn't realize that was valid markdown though, interesting...
content/guides/output-management.md
Outdated
Time: 539ms | ||
Asset Size Chunks Chunk Names | ||
vendor.bundle.js 544 kB 0 [emitted] [big] vendor | ||
app.bundle.js 2.81 kB 1 [emitted] app |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you'll need to include the CommonsChunkPlugin
for this to work -- meaning I think your app.bundle.js
will actually have lodash
included in it as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's discuss this one, maybe there's a simpler example that we can use as we should probably hold off on introducing the CommonsChunkPlugin
until Code Splitting.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You seem to be right, maybe we can just remove the lodash import from the main script for this example?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That could work, however then the vendor
bundle wouldn't really be used anywhere. How about we leave lodash
but don't extract it and instead of vendor
we add separate entry script that does something else to the page? This way that second bundle will be automatically included by the HTMLWebpackPlugin
(i.e. it should serve as a good way to illustrate the ideas of this article) but doesn't require any extra complexity in terms of plugins or configuration.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I didn't think about that.
Adding something else in might be a good idea, what would you propose?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmmm I'll give this some thought. Nothing jumping to mind at the moment. Maybe inserting another button that does something?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Scratch this.
How about something like a print.js
script that outputs something on the console.
We import it in index.js
and attach it to a button.
With the HtmlWebpackPlugin
it then gets automatically added.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
BTW, I've set up a repo to host the code examples for the guides.
It's under my account for now, but we could move it over to the webpack organization, that would be fine by me.
I'll go through the output-management
code examples, based off the end state of the asset-management
one and I'll see what I can add as a vendor entry that makes sense.
content/guides/output-management.md
Outdated
vendor: ['lodash'] | ||
}, | ||
+ plugins: [ | ||
+ new HtmlWebpackPlugin() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Two things... I think you need to first show that the old index.html
file is removed, maybe via a project diff or at least make it clear that it's getting overwritten. The current setup will just overwrite the old one. The second, I think you should pass a title here:
HtmlWebpackPlugin({
title: 'Output Management'
})
content/guides/output-management.md
Outdated
|
||
To generate multiple HTML files, say for a multi-page web application, you can utilize the [`MultipageWebpackPlugin`](https://github.com/mutualofomaha/multipage-webpack-plugin). This plugin is similar to the `html-webpack-plugin`, in fact it uses that plugin under the hood, however it can be used to generate an HTML file per entry point. | ||
## Cleaning up the `/dist`folder ## |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you need a space between /dist
and "folder". I do like the mention and use of the clean-webpack-plugin
, and I think with these two included we should basically stop diff
ing or showing the files within /dist
in our project diffs.
content/guides/output-management.md
Outdated
|
||
## The Manifest |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why scrap this section? I know it's not easy to do a fully fleshed out example but we could leave it in for now and just say something like:
We're not going to go through a full example of how to use this plugin within our projects but here's the basics and you can read through the plugin's documentation to learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I honestly thought it was way too advanced to be useful, but I'll add it back in with some adjustments and link off to the right resources in case people are interested in it.
content/guides/output-management.md
Outdated
template: 'src/index.html' | ||
- }) | ||
+ }), | ||
new CleanWebpackPlugin(['dist']) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe put this before the HtmlWebpackPlugin
as logically it comes first -- e.g. /dist
is first stripped of old contents and then new contents is added.
content/guides/output-management.md
Outdated
|
||
## Conclusion ## | ||
|
||
Now that you've learned about dynamically adding bundles to your HTML, let's dive into the next guide where this will be very useful: [`Code Splitting`](/guides/code-splitting). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Even though Code Splitting points to this as a pre-requisite, I think we should just point to the next guide down which I believe is Development so people can go through in order. You could also point to both and mention that Code Splitting is more advanced.
content/guides/output-management.md
Outdated
In most cases you probably want to provide a certain template to the `HtmlWebpackPlugin`, so that you can still have your own `index.html` file, but have webpack automatically add generated files. | ||
|
||
|
||
## Adding a template to HtmlWebpackPlugin ## |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would drop this as an entire section and, if anything, just mention that you can pass a custom template if necessary, maybe linking to that . It's also probably worth linking to the popular html-webpack-template package as you can get pretty far with that.
I have multiple projects that use this plugin and haven't needed to write a custom template -- plus the things you added with the custom template are available from the base plugin (and almost anything else you'd need is available from html-webpack-template
). I know this might sound nitpicky but I think we should really try to avoid replicating documentation and instead focus on just introducing a variety of approaches and then let the user take their own path from there.
content/concepts/manifest.md
Outdated
@@ -38,5 +38,3 @@ As the compiler enters, resolves, and maps out your application, it keeps detail | |||
So now you have a little bit of insight about how webpack works behind the scenes. "But, how does this affect me?", you might ask. The simple answer is that most of the time it doesn't. The runtime will do its thing, utilizing the manifest, and everything will appear to just magically work once your application hits the browser. However, if you decide to improve your projects performance by utilizing browser caching, this process will all of a sudden become an important thing to understand. | |||
|
|||
By using content hashes within your bundle file names, you can indicate to the browser when the contents of a file has changed thus invalidating the cache. Once you start doing this though, you'll immediately notice some funny behavior. Certain hashes change even when their contents apparently does not. This is caused by the injection of the runtime and manifest which changes every build. | |||
|
|||
See [the manifest section](/guides/output-management#the-manifest) of our _Managing Built Files_ guide to learn how to extract the manifest, and read the guides below to learn more about the intricacies of long term caching. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See my comment below re the manifest -- if we do leave that section in then we should leave this in as well.
content/guides/output-management.md
Outdated
|
||
## The Manifest | ||
|
||
You might be wondering how webpack and its plugins seem to "know" what files are being generated. The answer is in the manifest that webpack keeps to track how all the modules map to the output bundles. I fyou're interested in manageing webpack's [`ouput`](/configuration/output) in other ways, the manifest would be a good place to start. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/s/I fyou're/If you're
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/s/manageing/managing
content/guides/output-management.md
Outdated
|
||
The manifest data can be extracted into a json file for easy consumption using the [`WebpackManifestPlugin`](https://github.com/danethurber/webpack-manifest-plugin). | ||
|
||
Were not going through a full example of how to use this plugin within your projects, but you can read up on the [`manifest concepts`](/concepts/manifest) and the [`Caching`](/guides/caching) guide to find out how this ties into long term caching. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Were not going...
might sound better as We won't go through...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At some point a small manifest example here would be good (the current 200 lines actually isn't bad so adding to this probably wouldn't be overwhelming). Maybe using the manifest to accomplish the same thing as above in a custom way could be cool if it can stay fairly concise. The problem is I don't think either of us has experience with this so maybe someone will volunteer or one of us could dig into it at some point.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I agree, an example would be cool, but maybe someone with more experience can chip in on that, would be greatly appreciated!
@skipjack ready for merge ;) |
@TheDutchCoder nice work on this! Once I finish reviewing the backlog of PRs, I'll touch base with you on #1258. |
Thanks man! More updates to follow once the examples are put in place :) |
Rewrite of this guide as a logical follow up of the
Asset Management
guide.(Will add more advanced example with multiple assets later)