cacheFile not working

[G-Rath]

Title says it all; the cacheFile field doesn't result in a cacheFile being generated or used.

I'm using [email protected], [email protected], [email protected], and right now it actually isn't even generating the cacheFile - Normally when/if it does, it'll always just be a blank empty file.

If I run browserify-incremental, that works fine, and the cacheFile it generates will be used once by grunt-browserify, before replacing it with an empty file.

If I type in anything (be it an empty object {} or asdf), the cache file seems to be ignored - only when it's a valid cache does it seem to be replaced with an empty file afterwards.

The console output looks like it thinks it's writing to cache:

Running "browserify:dev" (browserify) task
>> 11101719 bytes written (3.52 seconds)
>> Bundle public/static/js/main.js created.

I'm using the aws-sdk, and so would really, really love to have this working, since my js build time is currently 2 seconds with an end size of about 10mb.

These are my grunt dependencies:

        "browserify-incremental": "^3.1.1",
        "grunt": "^1.0.1",
        "grunt-browserify": "^5.2.0",
        "grunt-contrib-clean": "^1.1.0",
        "grunt-contrib-copy": "^1.0.0",
        "grunt-contrib-eslint": "0.0.5",
        "grunt-contrib-less": "^1.4.1",
        "grunt-contrib-watch": "^1.0.0"

(I included browserify-incremental just on the off chance it might help).

I'm running Windows 10, have had no errors or exceptions given to me by Node, NPM, Grunt, Grunt-Browserify, Browserify-Incremental, or anything else to indicate that anything is amiss.

I've stuck console.log calls with the properties in the actual runner.js file, with all signs seeming to indicate that the cacheFile property is being passed correctly, and that there are no errors happening.

I've tried hard-setting the cache location to a number of places, including to C:\cache.json, with no luck (not even errors, which is actually what I expected would happen, because Windows/UAC).

I've tried running directly from IntelliJ (via it's Grunt command window), from PowerShell in IntelliJ, and in an admin-elevated PowerShell outside IntelliJ; all with no luck or change.
command window), from PowerShell in IntelliJ, and in an admin-elevated PowerShell outside IntelliJ

I've not got a lot of time on my hands right now, so I'm a little loath to do any 'try with a fresh new project stuff' (I'll do it, but it might just take a day or two, and I'll grumble under my breath while doing so), but I'm happy to try and provide as much extra information as I can, if I've missed something (and try new things with my current project of course).

[G-Rath]

@taoeffect and @DirtyHairy

I hope you guys don't mind roping you into this issue, but I'm very keen to find a solution (actually it would be nice to even just find the problem).

I'm happy to try and fix this myself with a little guidance and assistance when possible; since you two wrote and reviewed the original PR for this (respectively) I figured you two might know more information, or even just be able to confirm if it was actually working for you.

Thanks.

[DirtyHairy]

Hi @G-Rath ! I have seen the issue, but have not yet found time to look at it myself. I'll see if I can reproduce and troubleshoot it the next few days.

[G-Rath]

Fantastic! that's exactly what I wanted to hear :) Thanks, let me know what you turnup

[G-Rath]

Any update on this? If theres anything I can do to help speed things along, please let me know :)

[DirtyHairy]

Sorry for the delay, I promise to look at it this weekend 😏

[taoeffect]

@G-Rath I believe @DirtyHairy closed my PR and then manually added a subset of the changes I made, and that those changes shouldn't be materially different from what is in my branch (the exception being the existence of a package-lock.json file, and precise version dependencies).

I can say that I did notice that sometimes I experienced the cache file not being used, but that this odd behavior would go away with a few more file saves, and didn't seem to come back. I'm not entirely sure what causes that behavior, or whether it's the same thing you're experiencing, but I also am not in a position at the moment to fully investigate this myself right now.

[taoeffect]

@DirtyHairy Could you confirm whether saving the project a few times makes the problem eventually go away?

[G-Rath]

@taoeffect I have seen an effect similar to what you describe - the browserify-cache.json file tends to be created after a couple of saves, but never with content. It's always empty.

The same happens if I put any content in the file: Usually after about two runs, the browserify-cache.json file will be wiped.

I did wonder if it might be related to the fact that I'm using aws-sdk, since it's a large library - I wondered if maybe it was something like the grunt-browserify task ending before the cache stream has finished writing? Or that because of the library size, the stream gets chucked somewhere?

[G-Rath]

Weirdly enough, the part about the cache file being wiped only seems to happen when I tried applying the fix from this PR request on browserify-cache-api.

From the sounds of some of the comments made on that PR, I wondered if that was the problem, but applying the suggested change didn't change anything (aside from what I mentioned above).

The weird thing about all this (in my mind - it might not seem as weird for people who know the system) is that browserify-incremental works fine via command line.

The only thing I can think of right now is the idea that somewhere there's a stream that's not being allowed to finish writing, or that for some reason it's just overflowing and throwing out all it's data, thus writing nothing.

[DirtyHairy]

As promised, I'll do a few tests with one of my own projects later. However, a race with a stream being closed to early sounds like a very likely explanation for what you are observing (and would also explain why I observed no issues when I merged the PR). Unfortunately, this might be out of the scope of the grunt plugin to fix, but let's not be hasty 😏

[DirtyHairy]

I can indeed reproduce the behavior here: the cache file always has size zero. I have prodded the code a bit, and it seems that storeCache here is called correctly, but grunt exits before the file is written to disk. This is very weird --- node should wait until the event loop is empty before it exits --- but I have encountered similar issues with grunt before: it seems to exit in a way that prevents proper cleanup by node.

An event is fired on the browserify instance once the cache file is written, so I think we can work around this issue by delaying the bundle task until the event (or the corresponding error event) has fired. I'll look into this later this week.

[G-Rath]

Has any progress happened with this?

[taoeffect]

@G-Rath none from my end as I haven't been able to reproduce this, however, I am also probably running an older version of browserify by this point (haven't updated deps in a while), so if you're right that it's an issue with a change in browserify then ... well.. not much I can do.

Perhaps @DirtyHairy's workaround might work, and if I had the time I would try implementing it myself, but I unfortunately do not. Am just swamped at the moment.

If you're a good JS dev though it shouldn't be difficult for you to try his idea out yourself.

[DirtyHairy]

@G-Rath Sorry, no. I wanted to give it a shot, but couldn't find time and then forgot about it... 😏 Thanks for the reminder, I'll see what can be done the next days.

[sekoyo]

I had the same issue but a fresh npm install with latest versions of grunt tooling fixed it

[G-Rath]

I've got everything up to date, but still no dice sadly :(