jsonOutput doesn't play well with watchify + symlinks

[chiel]

Hi there, I'm having an issue with css modules when used in combination with watchify.

The problem seems to be that on the first run, symlinks don't get resolved properly, but they do on subsequent runs triggered by watchify. This leads to paths varying between runs and the styles.json not being output correctly.

Example

Let's say I have the file ./dist/app/styles/app.css, which is also symlinked as ./node_modules/app/styles/app.css, with the following contents:

.container {
    min-height: 100vh;
}

Running this through watchify + css-modulesify with the rootDir set to process.cwd() + '/node_modules' will generate a json file that looks like this (prettified for convenience):

{
    "app/styles/app.css": {
        "container":"_app_styles_app__container"
    }
}

Perfect, this is exactly what you'd expect. However, saving app.css will trigger a rebuild in watchify so a new json file is generated with the following contents:

{
    "app/styles/app.css": {
        "container":"_app_styles_app__container"
    },
    "es/app.css": {
        "container":"_dist_app_styles_app__container"
    }
}

As you can see there are two issues here:

1. The file path is wrong, and looks very odd, being clipped off like that (this is actually due to how the normalised file paths are being generated, based on the rootDir option).
2. The generated class name is different, and contains the extra _dist part at the start of it.

I am not sure why the results vary between runs, nor am I sure why the _dist gets added, but my gut feeling is that this issue can potentially be solved by always using something like fs.realpath() to resolve any symlinks that might be in place.

I have been looking into the code and started debugging things a bit, so I can hopefully come up with a solution and open a pull request but I just wanted to create this issue to see if anyone else is running into a similar issue, or if there is an easy fix for it.

[chiel]

Alright, so starting debugging at the top of the chain helps a lot. It looks like the path passed in by browserify/watchify is already wrong. The first time it's the unresolved path, and the second time the symlink has been resolved.

I'll go look into browserify and see if I can figure out why this happens.

[joshwnj]

Thanks for the report @chielkunkels , I'll see if I can find some time to take a look :) But otherwise please let us know what you find in the meantime.

[chiel]

@joshwnj thanks for the quick reply. Sadly I didn't have too much time to look into it yesterday, since I encountered this during working hours. I did try debugging the browserify code a bit, but I find it quite difficult to grasp.

Though I have used browserify for over 4 years now, I've never had to write a browserify plugin so that is also kinda new territory to me.

In all the places I've tried to log file paths in the browserify code, the resolved path came out, so I am a bit confused why the unresolved path is being fed into cmify. As a quick test I tried to simply replace this line with:

this._filename = fs.realpathSync(filename);

But browserify doesn't seem to like that and subsequently errors out with:

Error: Node does not exist: /Users/chiel/dev/image-editor/dist/app/styles/app.css while parsing file: /Users/chiel/dev/image-editor/node_modules/app/styles/app.css
    at Object.DepGraph.dependenciesOf (/Users/chiel/dev/gulp-tasks-poki/node_modules/dependency-graph/lib/dep_graph.js:139:13)
    at /Users/chiel/dev/gulp-tasks-poki/node_modules/css-modulesify/index.js:169:30

Which I suppose makes sense since the path is being altered or so - this is where my lacking knowledge of authoring browserify plugins kinda stops me. I tried looking up documentation about what methods etc are expected but I ran out of time to really dig in.

Hope this helps somewhat, I will try to make some more time today but I can't make any guarantees.