Code Monkey home page Code Monkey logo

Comments (19)

rdrey avatar rdrey commented on March 29, 2024

I'm looking forward to these changes. Let me know if I can help somehow.

from webpack.

Phoscur avatar Phoscur commented on March 29, 2024

I like that you are going to rethink the options object. Try to use convention over configuration when possible, find good default values.

from webpack.

sokra avatar sokra commented on March 29, 2024

Current state of design:

The webpack function will stay for backward compatiblity.

There is are new public Compiler class which encapsulate the overall process. It offers the convenience methods run and watch.

The Compiler creates a instance of Compilation for each run. It builds the dependency tree and splits it into chunks and other assets. It offers the methods process(context: String, entry: Dependency, callback) and getStats(). It also offers access to the properties entry: Module chunks: Chunk[] modules: Module[] assets: Object<String, String | Buffer>.

The Dependency class hierachy currently has the subclasses ModuleDependency (with subclasses for each type of apperance in source i.e. CommonJsRequireDependency, AMDRequireDependency, ...) and ContextDependency (also with subclasses).

In a Compilation you can map a class of Dependency to a ModuleFactory and a DependencyTemplate. The ModuleFactory creates a Module from a Dependency by resolving. The DependencyTemplate specifies the output source for a Depedency once the Module has a id. The Compiler do the setup for the mappings.

Some classes inherit from a Tapable interface, which means they offer a plugin interface for extending. Currently the classes Compiler, Compilation and Parser. I.e. the Parser is stupid and just ask plugins if it want to make a method call to a statically analysed method.

So the Compiler creates a Parser and map statically analysed methods to functions which returns Dependencys.

The Compilation asks plugins for optimizing the chunks. The Compiler adds some basic plugins which remove modules which are referenced in the parent module and remove empty chunks. The current maxChunks options will result in a plugin which merges modules. (Here is a good place to intergrate some stuff which is on the todo list, like leftover chunk)

MainTemplate, ChunkTemplate and ModuleTemplate will do the outputing, so you may subclass them to provide own stuff. (SingleMainTemplate, JsonpMainTemplate, JsonpChunkTemplate, FunctionModuleTemplate, EvalDevToolModuleTemplateDecorator are provided and set by the Compiler). The templates may also offer a plugin interface to extend them.

Also node.js / IO specific stuff is in the classes NodeCompiler, NodeFileEmitter, NodeResolver and NodeSubProcessExecutor. I hope somebody will implement a NodeThreadsAGoGoExecutor 😄 . That would be much better.

There is more stuff, this is just a overview. Any comments? Any stuff whichs should be extendable?

from webpack.

sokra avatar sokra commented on March 29, 2024

Which loaders should be included in webpack? Here is a list.

from webpack.

jhnns avatar jhnns commented on March 29, 2024

I favor your attempts to simplify the API. The current options-object is very complex and seemed a little odd to me (e.g. the resolve/postprocess-thing).

I'm not sure if I got your explanation right, but I like your idea of a Compiler- and a Compilation-Class. Could you provide us some example code of how the webpack API will be?

Such as

var webpack = require("webpack"),
    Compiler = webpack.Compiler,
    ModuleTemplate = webpack.ModuleTemplate,
    MyModuleFactory = require("../MyModuleFactory.js"),
    myModuleFactory = new MyModuleFactory(),
    compiler = new Compiler();

var compilation = compiler.run("/my/folder");

compilation.on("dependency", function (dependency) {
    myModuleFactory.resolve(dependency);
    // etc
});

So what happens to loaders? How do they fit in the new architecture?
I don't think that webpack should ship more loaders. Your list is sufficient.

from webpack.

sokra avatar sokra commented on March 29, 2024

Loaders are the best thing :) and will stay.

I think I will ship webpack without the loaders, and you have to install every loader you need... So it stay more lightweight.

The standard usage of webpack will be (as before) the webpack method:

webpack({
  context: __dirname,
  entry: "./file.js",
  output: {
    path: path.join(__dirname, "public"),
    filename: "mybundle.js"
  }
}, function(err, stats) {
  if(err) throw err;
  console.log(stats.toString({
    colors: true
  }));
});

The options have been refactored. There is a plugin interface, so i hope many stuff can move into a plugin. (at options.plugins)

An example plugin for changing a path after resolving:

function MyPlugin() {
};
module.exports = MyPlugin;
MyPlugin.prototype.apply = function(compiler) {
  compiler.resolver.plugin("module-resolved", function(result, callback) {
    callback(null, result.replace(/x/g, "y"));
  });
};
var MyPlugin = require("./myPlugin.js");
webpack({
  // ...
  plugins: [new MyPlugin()]
}, callback);

The other (more advanded) way is the Compiler API, which is internally used by the webpack method:
(I'm not yet happy with this, but that is the current state)

var c = new Compiler();
c.context = __dirname;
c.entry = new SingleEntryDependency("./file.js");
// or: new SingleEntryPlugin(__dirname, "./file.js").apply(c);
c.options.output = {
  path: path.join(__dirname, "public"),
  filename: "mybundle.js"
};
// or: new OutputLocationPlugin(path.join(__dirname, "public"), "mybundle.js").apply(c);
new NodeEnvironmentPlugin().apply(c);
new JsonpTemplatePlugin().apply(c);
new FunctionModulePlugin().apply(c);
new EvalDevToolModulePlugin().apply(c);
new MyPlugin().apply(c);
c.run(function(err, stats) {
  // ...
});

The plugin system has the intend that a library could provide a plugin which does the configuration... I. e. a jade plugin which binds the extension to the correct loader. The user just have to use the plugin. (maybe with --use jade-plugin)

from webpack.

sokra avatar sokra commented on March 29, 2024

Progress:

  • Core
  • Resolver
  • extract core into extra module
  • contexts
  • AMD
  • enhanced-resolve
  • optimizing chunks
  • extract loaders into extra modules
  • let enhanced-require also use it
  • beta
  • upgrade tools
  • upgrade some loaders

from webpack.

jhnns avatar jhnns commented on March 29, 2024

Seems reasonable to me. 😄 How does the compiler interface look like? Don't make it too granular and complicated. For me there are two important parts:

  • Resolving modules (including compilation of modules like CoffeeScript)
  • Outputting modules

I wouldn't separate path lookup and compilation (as it was with webpack 0.6.x). A loader may change the path and/or compile a module.

I like the idea of loaders, but I'm still not a big fan of enhanced-require. It is not CommonJS-style and makes the module unconsumable for other bundlers. It's ok to depend on a specific bundler when developing an application. But a library should not depend on a specific bundler.

from webpack.

sokra avatar sokra commented on March 29, 2024

Compiler interface:

var compiler = new Compiler();
// <- Attach plugins to the compiler
// Choose one of "run", "watch" oder "compile"
compiler.compile(function(err, compilation) { /* ... */ }); // compile and return a Compilation
compiler.run(function(err, stats) { /* ... */ }); // compile and write to files
compiler.watch(function(err, stats) { /* ... */ }); // like run, but rerun on change

At least you have to attach this plugins:

  • an environment plugin, i. e. NodeEnvironment
  • plugins for the output format, i. e. JsonpTemplatePlugin and FunctionModulePlugin
  • a plugin for the entry, i. e. SingleEntryPlugin

Even better is if you attach a plugin for a require style, i. e. CommonJsPlugin ;)

Some of the plugins take options.

Example:

var compiler = new Compiler();
var context = __dirname; // root for resolving entry and shortening stuff
var plugins = [
  new NodeEnvironmentPlugin(outputPath, resolveOptions),
  new JsonpTemplatePlugin({ filename: "bundle.js" }),
  new FunctionModulePlugin(context),
  new SingleEntryPlugin(context, "./entry.js"),
  new CommonJsPlugin()
];
plugins.forEach(function(p) { p.apply(compiler) });
compiler.run(function(err, stats) {
  if(err) return console.error(err);
  console.log(stats.toString({ colors: true }));
});

This would be a very basic build.

The webpack function is a helper which decides by a passed options object, which plugins are attached.

from webpack.

sokra avatar sokra commented on March 29, 2024

Here is a bit of documentation for the current plugins: https://github.com/webpack/webpack/wiki/Plugins

from webpack.

jhnns avatar jhnns commented on March 29, 2024

Looks good! But I'm not sure about the NodeEnvironment-plugin. Is webpack really designed to run in other environments than node?

from webpack.

sokra avatar sokra commented on March 29, 2024

Currently not, but I may want to add an online demo, so it would be cool if it could run in the browser (of couse bundled with itself ;) ). Maybe to worker loader also need another environment, not sure yet.

from webpack.

jhnns avatar jhnns commented on March 29, 2024

Ahh headache ^^

from webpack.

sokra avatar sokra commented on March 29, 2024

Next week I may have some time to make good progress with 0.9

from webpack.

jhnns avatar jhnns commented on March 29, 2024

Yeah! 🚀

from webpack.

sokra avatar sokra commented on March 29, 2024

webpack-progress

require.context is still missing...

from webpack.

sokra avatar sokra commented on March 29, 2024

require.context and automatic context is now working...

webpack-progress

some node.js tests are failing...

from webpack.

sokra avatar sokra commented on March 29, 2024

webpack-progress

yeah...

  • watch mode
  • chunk numbers
  • caching
  • progress display
  • executeable

from webpack.

jhnns avatar jhnns commented on March 29, 2024

🚀 🚀 🚀

from webpack.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.