Factor out sections that can be

[fresheneesz]

There is an impressive ton of code in this project. I have a gut feeling that much of the functionality in here can be separated out into a different project and used on its own (without adding in all the other functionality webpack provides). Its hard to contribute to a project like this. I'd like to look into that, since it might supercede what I'm doing https://github.com/fresheneesz/asyncify , but I'm worried I won't be able to understand the code well enough to contribute.

Don't build a framework, or a monolithic library. Build weakly coupled module ; ) .

[sokra]

Don't be scared by that many files in this project. Most files contain less that 50 lines. Webpack uses it's own plugin system internally. Every feature is added by an separate plugin. This causes small files. The core (Compilation, Compiler) shouldn't be to hard to understand.

If you need some features there are ways to add them without the need to change any internal: loaders and plugins.

Loaders are code generators / preprocessors. Examples: coffeescript, jade

Plugins extend the compiler with features. Examples: compression, i18n, component

There is some documentation here: https://github.com/webpack/docs/wiki
It's not yet complete, so feel free to ask anything 😄

EDIT: http://webpack.github.io/docs/

[fresheneesz]

Alright, fair enough about the small components. But couldn't some of these things be split out into separate packages? It would be nice if the core was its own self-contained project that this project depends on (or at least put in a separate folder from all the plugins). By the same token, it would be nice if various parts were separated out into their own, independently useful libraries - things like Parser.js and Compiler.js maybe? Its really hard to tell because I haven't seen a single comment about how functions are intended to be used.

[altano]

@fresheneesz, it might be helpful if you provided more concrete examples of what you're talking about. For example, mention a specific component, how it could be separated out, how webpack would benefit from it being separated out, and an example of a kind of project other than webpack that could make use of it.

[fresheneesz]

I'll have to dive into webpack at some point to properly answer your questions.

[sokra]

😄 I'm thankful for every architectual hint... and for every new user...

[jhnns]

webpack is awesome and far better than all other bundlers I've been using so far. We need a better introduction for new users, but there's so much to do 😉

[altano]

I agree @jhnns: it's a little daunting to dive into a project that is a little sparse on the documentation and has such a small user base, but on the flip side it was obvious to use webpack for my project given how much better it was than all the other loaders when I did my investigation. I am using it for a bookmarklet and it is amazingly well suited to that task.

I know I've been lazy about doing the few TODOs I have noted to myself (like responding to @sokra's code review of handlebars-loader and writing an article on my experience using webpack), but if you guys have any ideas for more urgent contributions I'd be happy to make them. For example, if you have a specific area of the documentation that could use some fleshing out, or anything like that, just assign a task to me and I'll take care of it.

[sokra]

The following components should be separate modules:

• parser
• loader runner
• sources

[fresheneesz]

@altano Ok sorry it took me so long. In addition to what sokra mentioned:

• The watcher - one that I suggested elsewhere, and seems that's now done
• The logic that builds the tree of files that need to be bundled (maybe this is what sokra meant by 'parser'). Specifically, I'd like to use this to help build the deployment package for my project - I want to take a piece from my repo and package all the files it requires to run. This is only one piece in the repo, so packaging together all the files (what i'm currently doing) means there is a LOT of unnecessary copying going on.

It sounds like sokra has taken this to heart for various internals i'm not familiar with, which is great!

[jhnns]

I think, the issue's topic is a more general one @sokra is constantly working on to improve it. Can we close this?

[fresheneesz]

@jhnns Yeah we can probably close this. I'll leave it up to you tho.