Webpack - No Output File, No Errors Reported

[Kay2dan]

I am learning Webpack and going through it again and again. In the latest build, there is something very strange going on. CLI reports everything is well & the output file dress_aphrodite.js is emitted, yet its nowhere to be found in the folder.

Here are the logs:
From CLI:

http://localhost:8080/webpack-dev-server/
webpack result is served from /app/
content is served from ./app
Hash: 5334867c12acfa65ba90
Version: webpack 1.12.9
Time: 1966ms
                    Asset    Size  Chunks             Chunk Names
    dress_aphrodite.js  390 kB       0  [emitted]  main
dress_aphrodite.js.map  479 kB       0  [emitted]  main
chunk    {0} dress_aphrodite.js, dress_aphrodite.js.map (main) 354 kB [rendered]
    [0] multi main 52 bytes {0} [built]
    [1] ./~/babel-polyfill/lib/index.js 209 bytes {0} [built]
    [2] ./~/core-js/shim.js 4.31 kB {0} [built]
    [3] ./~/core-js/modules/es5.js 10.2 kB {0} [built]
    ...
  [263] ./~/ansi-regex/index.js 135 bytes {0} [built]
webpack: bundle is now VALID.

So everything looks good above. Yet, there is no dress_aphrodite.js file in the main folder or ./app folder.

Here is the webpack.config.js file:

    var path = require ('path');
    var webpack = require ('webpack');

    module.exports = {
        entry : [
            'babel-polyfill',
            './app/da',
            'webpack-dev-server/client?http://localhost:8080'
        ],
        resolve : {
            extension : ['', '.js', '.jsx', '.json']
        },
        output : {
            publicPath : '/app/',
            filename : 'dress_aphrodite.js'
        },
        debug : true,
        devtool : 'source-map',
        devServer : {
            contentBase : './app'
        },
        module: {
            loaders: [
                {
                    test : /\.js$/,
                    include : path.join (__dirname, 'app'),
                    loader : 'babel-loader',
                    query : {
                        presets : ["es2015"]
                    }
                }
            ]
        }
    };

And finally, incase, anyone needs the package.json file, here it is:

    {
      "name": "dress_aphrodite",
      "version": "1.0.0",
      "description": "",
      "main": "dress_aphrodite.js",
      "scripts": {
        "start": "node_modules/webpack-dev-server/bin/webpack-dev-server.js"
      },
      "author": "",
      "license": "ISC"
    }

Any help as to why the output file is not being emitted / rendered?

Thanks

Edit: Tried without the Output.publicPath (as suggested by YuWu), still no change. Changed it to path property & still no change as well.

Edit 2: As a test, I added the html-webpack-plugin into the webpack.config.js file to see if it would be emitted by webpack and yes, apparently that too has been emitted and yet I cannot see.

Edit 3: (Post generous conversation with YuWu) : The webpack-dev-server is running fine and displaying the window.alert in the js file along with the dynamic html file created via html-webpack-plugin. I recall installing the webpack-dev-server globally. Could that be where the html & the js emitted files are being stored?

question posted on SO here

[bebraw]

Please note that webpack-dev-server runs in memory by design. If you want a real bundle, build through webpack.

[Kay2dan]

I ran the webpack command as well. It doesnt seem to store the file in the directory.

Also, the output properties should be respected and the bundle output should have been stored in the directory, no?

[bebraw]

I have a minimum build setup at my tutorial. Perhaps going through that would clear things up? You can also check out the official getting started. There might be something missing. It's hard to tell without having something to run.

[Kay2dan]

Thanks bebraw, appreciate the effort. I did infact go through your awesome SurviveJs first few chapters to get the handle on Webpack. YuWu from SO also ran the Github build I posted the link to and he had the output in the folder. Im thinking this is Ubuntu permission issue and thoroughly went through the read / write permission review and everything seems to be fine.

What is baffling is that Webpack reports in CLI that the output 'bundle' has been emitted, yet where, I dont know. I'll go through again the setup again and see how it goes. All the previous build gave me the 'Cannot resolve 'file' or 'directory' error.

[Kay2dan]

After combing through it line by line, the culprit seems to be this:

 devtool : 'source-map', // same for 'devtool : 'eval-source-map'

• Running the webpack command with the above line en-abled, gives no output, even though Webpack reports zero errors (in CLI) and that relevant 'html' & 'js' files have been emitted.
• Running the webpack command with the above line dis-abled, gives the emitted files in the folder.
• Running the dev-server (through npm start hook) with the above line en-abled, doesnt report any error, the files emitted are not visible in the folder, however the server is reporting correctly and executing the code within the js files.
• Running the dev-server (through npm start hook) with the above line dis-abled, doesnt report any errors, the files emitted are not visible and again the server is running file, executing the code within the js files.

So, yes, the dev-server stores the emitted files in memory, however, why is the command not giving any error and making the files not appear in the folder?

devtool : 'source-map'

Do I need to install anything additional for devtool?

[bebraw]

Running the webpack command with the above line en-abled, gives no output, even though Webpack reports zero errors (in CLI) and that relevant 'html' & 'js' files have been emitted.

That sounds weird. If devtool : 'source-map', is set, running through webpack should generate you a .map file for each JavaScript it emits.

Feels like a bug to me.

Do I need to install anything additional for devtool?

I think it should just work out of box. You can try to dig into the dependency it uses to generate the sourcemaps. Digging into the source might be a good idea.

[Kay2dan]

Im not sure whether I should be embarrassed about this or not :!

• If the 'Output' directory (as specified in webpack.config.js) is not already present, its not created and the files are emitted (as reported by webpack CLI), however, the files are not to be found.
• If the 'Output' directory is present, then the devtool command works fine and the source file is created.

So sorry about this & thank you for the attention towards this @bebraw :!

[bebraw]

No worries. Great to hear you got it working. That behavior sounds a little strange to me (Ubuntu related quirk?). I set up a separate issue for that at #1746.

[landed1]

Thanks bebraw spent too long not knowing about the memory thing...

[ghost]

Thank you bebraw, that tip about the webpack-dev-server running in memory saved me from giving up and switching back to Gulp for my project.

[ldco2016]

Greetings,

I am unclear as to why webpack is not creating the app/js/main.js file that is in my webpack.config.js file. I have ran npm webpack install -g before and after creating the the webpack.config.js file and that main.js file still does not get created.

[bebraw]

@ldco2016 Can you open a question at Stack Overflow with your configuration? That will most likely yield a good answer. Thanks.

[saike]

Be sure, that your code is clean, and you have not return statements in your entry file. I had same problem, but then i realized, that it's if(!some) return; in my main file, so when i deleted it, bundle file appeared

[ilanc]

@Kay2dan I noticed that you don't have an output.path. Try adding output : { path: 'app/', }. NOTE not /app/.

I'm getting weird inconsistencies with webpack like you've described - i.e. no errors but no output and I'm not using devtool : 'source-map'. In my case it seems to work sometimes with output.path = /app/, and sometimes it doesn't produce output. But with output.path = app/ it seems to be working more consistently. I've only just discovered this issue so am not clear whether this fix works permanently.

NB there are some path relative issues:

1. I have config files in a subfolder - i.e. $/src/webpack.app.config.js
2. I run webpack from the root $/ - i.e. webpack --display-modules --config src/webpack.app.config.js
3. I output to /build/app.js

You can find the code in my style-loader bug report:

• https://github.com/ilanc/style-loader-bug
• style-loader removes .css when webpack.DllPlugin's used and module.id's overlap webpack-contrib/style-loader#163
  NB the code on github currently has path: '/build/' which seems to work sometimes (once?). Try change it to path: 'build/' for more consistent output.

As an aside there's a path inconsistency between output.path and require - the former is relative to root whereas the later is relative to the file AFAIK i.e.

output: {
      path: 'build/',
      filename: "app.js"
  },
...
plugins: [
    new webpack.DllReferencePlugin({
      context: ".",
      manifest: require("/build/dll1-manifest.json")
    })`

[ilanc]

Encountered this behaviour again with one of the RiotJS examples:
https://github.com/riot/examples/blob/gh-pages/webpack/webpack.config.js

changing path: '/public' to path: 'public/' makes it build properly. Weird. I'm running under mingw on windows 10 btw:

$ node --version
v4.4.0
$ uname -a
MINGW64_NT-10.0 IRONWILL 2.5.0(0.295/5/3) 2016-03-31 18:47 x86_64 Msys

[sym900728]

@bebraw I have read your survivejs/webpack book. That's excellent.

[monolithed]

I have the same problem. I need these files, when I develop some browser extensions

[bebraw]

@monolithed Can you open a separate issue? Make sure to fill the fields well.

[cooljl31]

I had the same problem but i could solve it by require this const path = require('path') and in my output object i add this line path: path.resolve(__dirname, 'dist/assets')

[zeus2198]

You can use this plugin to force the webpack dev server to write files to the disk!

[axelpale]

In my case I had path: path.resolve('../../static/js'), and it did not work. Then I added __dirname and it worked:

path: path.resolve(__dirname, '../../static/js'),

[skumar1708]

you need to run webpack command seperately to get output in build folder

[soxunyi]

If you delete /dist/ folder manually, please try run npm run init.

[unlight]

Same issue, figured out that problem related to uglifyjs-webpack-plugin@2.0.1,
rollback to uglifyjs-webpack-plugin@1.3.0 and it works again.

[Tecayehuatl]

What I did was to run the production mode: npm run build

"scripts": { "dev": "cross-env NODE_ENV=development webpack-dev-server --open --hot", "build": "cross-env NODE_ENV=production webpack --progress --hide-modules" }

and then it generates the output files

[smac89]

You can supply the writeToDisk option to have the files written to disk instead of in memory.

[waspar]

@smac89 our hero!

[Virushi]

Emm，I encountered a similar problem because the file name in the router is different from the case of the file name in src

[temple]

Sometimes, webpack fails when configuration has mistakes when using path library.
In my case, webpack run perfectly but produced no output.
My mistake was using an unnecessary slash in the output.path option.
Just compare
BAD: no output bundle file created**

output: {
  ..
  path: path.resolve(__dirname,'/dist')
  ..
}

GOOD: webpack produces the expected bundle file

output: {
  ..
  path: path.resolve(__dirname,'dist')
  ..
}

If the target output path is a valid folder, then webpack generates a bundle file, otherwise, will not, reporting zero errors.

So @Kay2dan, have you check how you use path?

[nyngwang]

It seems like the docs does not mentioned / put emphasis on the in memory idea pointed out by @bebraw.(many thanks btw) No search result on the page https://webpack.js.org/configuration/dev-server/#devserverwritetodisk- but I think it's better to be put on the first line in my point of view.

Here is my post on StackOverflow when I was trying to solve this problem with pictural answer for anyone who need a conclusion to this problem. (Indeed @temple 's reply directly above this solved my problem but I hadn't read it when I finished the SO post.)