Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cacheFile not working #397

Open
G-Rath opened this issue Sep 27, 2017 · 16 comments
Open

cacheFile not working #397

G-Rath opened this issue Sep 27, 2017 · 16 comments

Comments

@G-Rath
Copy link

G-Rath commented Sep 27, 2017

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

I'm using grunt-browserify@5.2.0, grunt-cli@1.2.0, grunt@1.0.1, 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
Copy link
Author

G-Rath commented Oct 2, 2017

@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
Copy link
Collaborator

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
Copy link
Author

G-Rath commented Oct 2, 2017

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

@G-Rath
Copy link
Author

G-Rath commented Oct 13, 2017

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

@DirtyHairy
Copy link
Collaborator

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

@taoeffect
Copy link
Contributor

taoeffect commented Oct 15, 2017

@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
Copy link
Contributor

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

@G-Rath
Copy link
Author

G-Rath commented Oct 15, 2017

@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
Copy link
Author

G-Rath commented Oct 15, 2017

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
Copy link
Collaborator

DirtyHairy commented Oct 15, 2017

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
Copy link
Collaborator

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
Copy link
Author

G-Rath commented Nov 27, 2017

Has any progress happened with this?

@taoeffect
Copy link
Contributor

@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
Copy link
Collaborator

@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
Copy link

sekoyo commented Jan 15, 2018

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

@G-Rath
Copy link
Author

G-Rath commented Apr 26, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants