__dirname not in relation to original location

Do you want to request a feature or report a bug?


What is the current behavior?

While using webpack for server side packing of node.js apps I am unable to have an accurate value for __dirname when __dirname is called within a required module, regardless of what options.node.__dirname might be set to.

If the current behavior is a bug, please provide the steps to reproduce.

For example, assume the following:

directory structure







const path = require('path');
module.exports = {
    target: "node",
    entry: {
      entry: './entry.js'
    output: {
      path: path.resolve(__dirname, 'dist'),
      filename: '[name].js'
    node: {
      __dirname: false

Steps to reproduce (assuming above files are in provided locations:

cd /my/app
cd dist
node entry.js

Expected Results:


Actual Results:


Results using the above files but based on various options.node.__dirname values within webpack.config.js:

value of options.node.__dirname result
false /my/app/dist
true other
empty line
unset /

What is the expected behavior?

I expect there to be an option to have __dirname‘s location be in relation to the directory of the current module that it was called from (before webpack) and not the directory name of the output file.

If this is a feature request, what is motivation or use case for changing the behavior?


Please mention other relevant information such as the browser version, Node.js version, webpack version and Operating System.

  • Node 6.9.5 LTS
  • weback 2.2.1
  • Windows 10

Author: Fantashit

3 thoughts on “__dirname not in relation to original location

  1. Because after bundling you have an one file, __dirname and __filename works the same as on a node, what do you expected? We can’t break node logic

Comments are closed.