Automatic preferation of .web.js-files doesn't work

[jhnns]

I'm not quite sure if I'm doing it wrong, but webpack uses the .js-file instead of the browser-compatible .web.js. This is my test setup:

// Creating bundle via API

var webpack = require("webpack");

webpack(__dirname + "/testEntry.js", {
    output: __dirname + "/testBundle.js"
}, function onWebpackFinished(err, stats) {
    if (err) throw err;
    console.log(stats.fileModules["testBundle.js"]);
});

// testEntry.js
var bla = require("./bla.js");

// bla.js
module.exports = "bla";

// bla.web.js
module.exports = "bla.web";

[ { id: 0,
    size: 81,
    filename: '[...]/testEntry.js',
    dirname: undefined,
    fromCache: undefined,
    toCache: undefined,
    reasons: [ [Object] ] },
  { id: 1,
    size: 69,
    filename: '[...]/bla.js',
    dirname: undefined,
    fromCache: undefined,
    toCache: undefined,
    reasons: [ [Object] ] } ]

bla.js and bla.web.js are in the same folder. The error occurs on linux and windows. My current webpack version is 0.4.12. Any idea? :)

[jhnns]

Same thing when using the command line.

[sokra]

require('./bla')

.web.js is the preferred extension for extension expansion. Specifying the complete filename do not try the .web.js extension.

[sokra]

https://github.com/sokra/modules-webpack#browser-replacements

[sokra]

If you want to enforce .web.js even for all .js files, you can archive this by a resolve postprocessor:

resolve: {
 postprocess: {
  normal: [
    function(filename, cb) {
      var file = filename.split("!").pop();
      if(!/\.js$/.test(file)) return callback(null, filename);
      file = file.replace(/\.js$/, ".web.js");
      fs.exists(file, function(exists) {
        if(!exists) return callback(null, filename);
        return callback(null, filename.replace(/\.js$/, ".web.js"));
      });
    }
  ]
 }
}

[jhnns]

Thanks, require('./bla') did the trick. I should read the readme more attentively ;).

What exactly is a postprocessor in webpack? Is this ability documented?

[jhnns]

Sorry, now I've read the next issue #7.