Let's ship the webpack 4 documentation - #1856
Conversation
This moves some of the content from `compiler.md` and brings it into the main node api documentation in order to allow `compiler.md` to become `compiler-hooks.md` which fits better in the context of plugins.
…le.md` This moves some of the `Tapable` discussion to the lead-in `plugins.md` to prevent doc duplication. Instead of redocumenting the `tapable` package, we should focus on improving the README and simply link to there throughout our docs. As I've mentioned before, we can also create a "Utilities" section for things other than "Loaders" and "Plugins" that we want to dynamically pull in.
These guides were full of todos and probably lead to more confusion than clarity. We can discuss more and add them back in once there's a clear flow for how to incorporate and document them.
This page now focuses specifically on the `hooks` as all the non-plugin related content was moved to `node.md`. I updated the hooks to the new syntax, added all undocumented hooks, reformatted each hook as a section to allow more breathing room, and clarified exactly which `tapable` hook is used for each section. Still need to get more info on some of the new hooks before we can ship this...
This page now uses the same section setup as `compiler-hooks.md` and is up to date with the latest hooks available in the webpack 4 alpha release.
Improve lead-in to give a little more context on what the parser does. Add the latest hooks and use the same layout as the other pages in the section.
Updates the Get Started guide to use webpack 4 and adds some additional information about npm.
Update the plugins page in the concepts section to be compatible with webpack 4. Also adds a note about referencing the plugin name in camel-case when calling the `tap` method.
|
We should definitely merge soon but whoever does please tag |
This adds the `builtAt` option to the example configuration.
This adds valid doctypes to all the HTML examples in the Get Started guide.
This adds a table of config options for v4 to the API documentation.
|
@TheLarkInn What you think about versioning the website? |
| T> For a high-level introduction to writing plugins, start with [writing a plugin](/contribute/writing-a-plugin). | ||
| Plugins are a key piece of the webpack ecosystem and provide the community with | ||
| a powerful way to tap into webpack's compilation process. A plugin is able to | ||
| [hook]() into key events that are fired throughout each compilation. Every step |
There was a problem hiding this comment.
[hook]() Missing a link here?
| T> Learn more about JavaScript modules and webpack modules [here](/concepts/modules). | ||
|
|
||
| It is [incredibly configurable](/configuration), but to get started you only need to understand four **Core Concepts**: | ||
| Since v4.0.0 webpack does not require a configuration file. Nevertheless, it is [incredibly configurable](/configuration). To get started you only need to understand four **Core Concepts**: |
There was a problem hiding this comment.
Can we rephrase this better? Maybe include "0CJS"?
| Every dependency is then processed and outputted into files called *bundles*, which we'll discuss more in the next section. | ||
|
|
||
| You can specify an entry point (or multiple entry points) by configuring the `entry` property in the [webpack configuration](/configuration). | ||
| You can specify an entry point (or multiple entry points) by configuring the `entry` property in the [webpack configuration](/configuration). It defaults to `./src`. |
There was a problem hiding this comment.
We should clearly mention the default filename along with directory. ./src/index.js
| ## Output | ||
|
|
||
| The **output** property tells webpack where to emit the *bundles* it creates and how to name these files. You can configure this part of the process by specifying an `output` field in your configuration: | ||
| The **output** property tells webpack where to emit the *bundles* it creates and how to name these files and defaults to `./dist`. You can configure this part of the process by specifying an `output` field in your configuration: |
There was a problem hiding this comment.
We should clearly mention the default filename along with directory. ./dist/bundle.js
| or pass it as a cli argument: | ||
|
|
||
| ```bash | ||
| webpack --mode=production |
There was a problem hiding this comment.
Can we also mention the precedence of mode if it's present in both config and via cli?
There was a problem hiding this comment.
--mode=production is valid too
There was a problem hiding this comment.
--mode production looks cleaner to me. Anyways, either is fine. 👍
| @@ -144,20 +177,25 @@ In this setup, `index.js` explicitly requires `lodash` to be present, and binds | |||
| With that said, let's run `npx webpack` with our script as the [entry point](/concepts/entry-points) and `bundle.js` as the [output](/concepts/output). The `npx` command, which ships with Node 8.2 or higher, runs the webpack binary (`./node_modules/.bin/webpack`) of the webpack package we installed in the beginning: | |||
There was a problem hiding this comment.
We should add a note or command here for users using Node < 8.2.
update tree shaking guide for webpack 4
* chore: clean package-lock.json * chore: sync yarn.lock
* correct a path error in example
|
Looks like a tree shaking guide is still conflicting. Does anyone want to grab those conflicts? |
|
@TheLarkInn Already resolved it a couple of days ago. #1923 |
* Update gitignore * Resolve conflicts * Resolve conflicts
|
Did a branch sync also via UI. |
TheLarkInn
left a comment
There was a problem hiding this comment.
I'm going to approve this. I feel pretty good about the state as is. Would someone be willing to open up.individual issues for things that look problematic from a content standpoint. Ideally we should get these surfaced to new contribs and more smaller PRs.
|
GitHub rate limit causing errors in CI. |
|
|
||
| Depending on the hooks used and `tap` methods applied, plugins can function in | ||
| a number of different ways. The way this works is closely related to the | ||
| a different number of ways. The way this works is closely related to the |
There was a problem hiding this comment.
Is the change in meaning intended here?
I'm no native speaker, but looks like before it said "there are many ways, and it depends which way it will be actually", and now it's says "there may be many or not so many ways, it depends"
There was a problem hiding this comment.
This is still evaluated the same.
There was a problem hiding this comment.
FWIW I'm a non-native speaker as well and the previous version of this sentence sounded more understandable to me.
There was a problem hiding this comment.
To me it sounds like the plugins, before, could work in various ways; but now it sounds like they work in a different amount of ways (???)
There was a problem hiding this comment.
the previous sounds clearer to me.
|
Finally 🎆 |
|
This review comment still applies: |
|
@edmorley would you be willing to create a separate issue for this and tie it to this PR so we have visibility and linkage? |
|
Sure - filed #1947 :-) |
Merge the next branch.