Skip to content
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

Merged
merged 15 commits into from
Jul 9, 2017
Merged

Updated output-management.md #1344

merged 15 commits into from
Jul 9, 2017

Conversation

TheDutchCoder
Copy link
Collaborator

Rewrite of this guide as a logical follow up of the Asset Management guide.
(Will add more advanced example with multiple assets later)

Rewrite of this guide as a logical follow up of the `Asset Management` guide.
(Will add more advanced example with multiple assets later)
@TheDutchCoder
Copy link
Collaborator Author

@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 HtmlWebpackPlugin configuration page which I link to.

@TheDutchCoder
Copy link
Collaborator Author

Travis seems to check for a #manifest anchor on this page.

I removed that section but I don't know how to update the link checker, help would be appreciated!

Fixed broken link
@skipjack
Copy link
Collaborator

I've rewritten this part of the guide, would love your feedback!

Will do as soon as I have a bit more time. Saturday at the latest, if not sooner.

Travis seems to check for a #manifest anchor on this page.

I removed that section but I don't know how to update the link checker, help would be appreciated!

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 .html page instead of the raw .md file). I can help more later on if needed.

@skipjack skipjack self-requested a review June 29, 2017 03:23
@TheDutchCoder
Copy link
Collaborator Author

@skipjack couple of newbee questions:

  1. How do I add another guide in my PR (say I want to also update Getting Started in this PR after I submitted it)?
  2. I can't seem to find out where that anchor is referenced. My best guess is the Fragment check: build/concepts/manifest/index.html line, but I can't seem to find that file anywhere.

Thanks!

@TheDutchCoder
Copy link
Collaborator Author

@skipjack Added section about cleaning up the /dist folder and removed reference to missing Manifest section.

@skipjack
Copy link
Collaborator

skipjack commented Jul 1, 2017

How do I add another guide in my PR (say I want to also update Getting Started in this PR after I submitted it)?

Just commit any other changes to the same patch-5 branch you should see them reflected here. Also -- I'm going to add you as a contributor to this repo seeing as you've contributed a lot of time/energy and helped us push things forward tremendously. This means you'll be able to git clone this repo directly and open/push branches in the main repo making it slightly easier to PR and collaborate.

I can't seem to find out where that anchor is referenced. My best guess is the Fragment check: build/concepts/manifest/index.html line, but I can't seem to find that file anywhere.

It looks like you fixed this by removing the section linking to it from the concepts page.


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.
Copy link
Collaborator

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.


__index.html__
## Preparation ##
Copy link
Collaborator

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...

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
Copy link
Collaborator

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.

Copy link
Collaborator

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.

Copy link
Collaborator Author

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?

Copy link
Collaborator

@skipjack skipjack Jul 5, 2017

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.

Copy link
Collaborator Author

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?

Copy link
Collaborator

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?

Copy link
Collaborator Author

@TheDutchCoder TheDutchCoder Jul 5, 2017

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.

Copy link
Collaborator Author

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.

vendor: ['lodash']
},
+ plugins: [
+ new HtmlWebpackPlugin()
Copy link
Collaborator

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'
})


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 ##
Copy link
Collaborator

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 diffing or showing the files within /dist in our project diffs.


## The Manifest
Copy link
Collaborator

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.

Copy link
Collaborator Author

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.

template: 'src/index.html'
- })
+ }),
new CleanWebpackPlugin(['dist'])
Copy link
Collaborator

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.


## 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).
Copy link
Collaborator

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.

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 ##
Copy link
Collaborator

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.

@@ -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.
Copy link
Collaborator

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.


## 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.
Copy link
Collaborator

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

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/s/manageing/managing


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.
Copy link
Collaborator

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...

Copy link
Collaborator

@skipjack skipjack Jul 5, 2017

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.

Copy link
Collaborator Author

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!

@TheDutchCoder
Copy link
Collaborator Author

@skipjack ready for merge ;)

@skipjack skipjack merged commit 297c5bc into webpack:master Jul 9, 2017
@skipjack
Copy link
Collaborator

skipjack commented Jul 9, 2017

@TheDutchCoder nice work on this! Once I finish reviewing the backlog of PRs, I'll touch base with you on #1258.

@TheDutchCoder
Copy link
Collaborator Author

Thanks man! More updates to follow once the examples are put in place :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants