[WIP] feat(api/plugins): create plugins api documentation

[TheLarkInn]

[WIP] This will be a big one, but I think we might as well get it started. I have fully scanned through the compiler calls for any applyPlugins****() functions, however I'm not 100% sure I have all the correct hooks.

• Describe the x ways to create a plugin
• Describe what tapable is, and how it relates to webpack
• Describe a 'tapable instance'
  • List All Tapable Instances
• List all hooks for all instances

[TheLarkInn]

Part of me wants to separate these in to separate docs now that I'm think about the whole divide and conquer aspect of things, but in regards to the layout of the documentation, it makes sense for these things to all be on one page. @bebraw @jhnns @SpaceK33z Thoughts?

[bebraw]

api/tapable/factories, api/tapable/templates and so on would work. api/tapable would work as a brief intro (high level view).

[TheLarkInn]

Continuing on my thought dump before I move on to something else for now: I wonder, is there any way that we could generatively find all of the webpack hooks? Like do a lib search for all of the tapable.prorotype protected methods at the least, and mention what file they come from, and then use this to fill in the details (IE: what tapable instance is this, what are the data points called).

[bebraw]

That sounds reasonable. recast can match the pattern if you can find a nice way to traverse the source (glob would work).

[SpaceK33z]

I don't have much experience with building plugins, so can't comment on the specifics. So far I like the structure.

Would it be possible to show an example of a very simple plugin and explain how it works? I think this would help many developers to actually get started quickly without scouting through the whole internet to find a piece of example code :).

[pksjce]

Referencing #36 here.

[pksjce]

Can I put in Tapable description from #36 here?

[TheLarkInn]

Yes that's fine.

[pksjce]

@TheLarkInn - Hey how do I contribute to this PR? You have this in a branch in your fork. I cloned your fork but I have no permission push to your branch. I'm not sure what git flow I should follow here.

[jhnns]

I agree with @bebraw 's suggestion on how to structure the content.

• First overview (How do you write plugins? What is a tapable? How do you hook into the compilation process?)
• Compiler, MultiCompiler
• Compilation
• ContextModuleFactory, NormalModuleFactory, ...
• Resolver
• Template, ChunkTemplate, ...

[pksjce]

bump @TheLarkInn I would love to take this up.

[TheLarkInn]

Oh hey! @pksjce Thanks for the bump. I literally just started looking into to continuing on this.

[TheLarkInn]

I was thinking about having this have a sub folder structure @bebraw @jhnns:

/api/plugins (index.md) (contains links to other sections)
/api/plugins/compiler (also has multi compiler)
/api/plugins/compilation 
/api/plugins/module-factories
/api/plugins/parser
/api/plugins/resolver
/api/plugins/template
/api/plugins/dependencies (how to work with, create, add custom dependencies [IE when to use Null and ConstDep, etc, vs create your own, and link back to template]).
/api/plugins/examples

[bebraw]

The structure looks good to me. I expect you can push some specific content below how tos (or guides) and cross-reference.

[TheLarkInn]

Closing in favor of #361