This is more of a question to see if anyone has had similar issues, nothing to do with the module as even without the module I can reproduce the error. I am not sure who else to get advice from.
I have the node module browser-sync installed, version 1.3.0. After this node package is present in my them, clearing cache via drush results in message of "Segment Fault: 11". Trying to clear cache via the UI, or even visiting a page results in a "No data sent" type of message from drupal. Removing this node module package let's make access the site again, along with clear cache via drush. I have repeated this about 15 times.
Spent hours researching Segment Faults, really not my area unfortunately.
At this point I am going to try installing an older version of browser-sync.
The gist of it I guess, whatever action of clearing caches somehow gets stuck in the node_modules folder and browser-sync and crashes the entire install.
Edit: I have also tried installing version 1.0.0
Edit: Installing 0.9.1 globally and within the theme results in NO segmentation fault errors.
Comments
Comment #1
humanaut CreditAttribution: humanaut commentedComment #2
humanaut CreditAttribution: humanaut commentedComment #3
jorgegc CreditAttribution: jorgegc commentedHi there,
I've had a similar issue where clearing the cache would result in Drupal picking up ".info" files from the "node_modules" within the theme folder, not being able to parse them and obviously breaking the site. The way around it was to move both my "Gruntfile.js" and "package.json" into a hidden folder within the theme called ".npm". Apparently Drupal doesn't bother looking for ".info" files in hidden folders so everything works as per normal.
Have a look at how I structure my theme folder here:
https://github.com/jorgegc/omega-essentials-starterkit
In particular these two lines of my Gruntfile:
https://github.com/jorgegc/omega-essentials-starterkit/blob/master/.npm/...
https://github.com/jorgegc/omega-essentials-starterkit/blob/master/.npm/...
Let me know how you go.
Comment #4
iainH CreditAttribution: iainH commentedThanks @jorgegc. This has identified the problem for me - namely Drupal cache-clear hoovering up stuff in the npm-related directories.
Deleting the node_modules directory resolved the problem - temporarily until the next
npm install
However, I now need to think of an equivalent to your solution as I am using a
gulpfile.js
rather than agruntfile.js
.Actually, no, that's not all I have to do. It's understand how hiding the
gulpfile.js
and thepackage.json
files in an .npm directory affect mygulp
workflow.Will post my findings.
Comment #5
iainH CreditAttribution: iainH commented[update May 2015]
I'm going with @iamcarrico #15 as being the cleanest workaround.
[previously .... also works ]
This works for me:
gulpfile.js
andpackage.json
to the new "hidden" directory.npm
cd .npm
andnpm install
(after having deleted theme root levelnode_modules
directory of course)gulpfile.js
base directory for source and destination file paths.e.g. In the snippet bellow "../" were prepended to pathsgulp
command from within the.npm
directoryExample directory structure for ihit theme
Head of gulpfile.js
Comment #6
jorgegc CreditAttribution: jorgegc commentedThat is exactly the same structure that my projects have. I am glad you also found your way around the issue :-)
Comment #7
humanaut CreditAttribution: humanaut commentedI have implemented this with my gulp setup and so far so good.
My co-worker @cottser is going to make an alias or something that will allow a theme designer to still run "gulp" from the theme root, instead of going into the new .npm folder.
Thank you!
Comment #8
jorgegc CreditAttribution: jorgegc commentedYeah, I have had to do something similar in my Guard file as well:
https://github.com/jorgegc/omega-essentials-starterkit/blob/master/Guard...
Anyway, I am glad it all worked in the end :-) Thanks for documenting your solution here in the issue and happy styling!
Comment #9
afoster CreditAttribution: afoster commentedI posted this issue to core. We should have some way to ignore these .info files inside of node_modules
https://www.drupal.org/node/2329453
Comment #11
iamcarrico CreditAttribution: iamcarrico commentedFor anybody who has come across this, I thought of a elegant solution--- which is to add a postinstall hook onto the npm install. This will find and remove all .info files within your node_modules folder after you run npm install. Add this to the end of your package.json file.
Comment #12
jorgegc CreditAttribution: jorgegc commentedHi @iamcarrico,
I am sorry but I will have to disagree with you. I personally don't think that "hacking" Node.js modules is an elegant solution. It is definitely a solution but not an elegant one.
My preferred temporary solution is still the hidden folder that is not picket up by Drupal.
Cheers,
Jorge
Comment #13
iamcarrico CreditAttribution: iamcarrico commentedThere is no "hacking" involved here, it is a common type of script to add to a package.json--- and the lcov.info files are just remnants of testing scripts. They are not needed for functional running of the packages.
I dislike the hidden folder idea, because it adds on a new layer of weirdness for my developers. It also prevents me from using compass-options, and opens up to settings being duplicated in the config.rb and gulpfile.js.
Comment #14
iamcarrico CreditAttribution: iamcarrico commentedFor those interested--- the .info file that is causing all the trouble is from the test coverage in some node packages. It is not needed for anything except for automated testing of the package.
Vinyl's Test Coverage
Comment #15
discipolo CreditAttribution: discipolo commentedthanks for #11
that helpend although i had to change it to
Comment #16
iamcarrico CreditAttribution: iamcarrico commentedYou are right discipolo, I had some backslashes before them to fix that issue, but I didn't notice D.o took them out. I updated my code sample too in case people come across it as well. Thx1
Comment #17
rymcveigh@discipolo is right, @iamcarrico's solution works (after the alteration in #15) and is much more elegant.
Note: You may need to use an external file called .npmrc with just the following content:
unsafe-perm = true
Comment #18
DomoSapiens CreditAttribution: DomoSapiens commentedYou can also set it in your local npm config.
This worked for me!
Comment #19
reikiman CreditAttribution: reikiman commentedFirst - isn't it a bug in Drush or Drupal Core if it is crashing on finding what it thinks is a malformed .info file? Rather than crash it should print an error and abort whatever it was trying to do.
Second - I can't think of a valid reason for a npm module to include something like test results in the packaged distribution. That's a sloppy package maintainer not adding things to their .npmignore file. The package maintainer should be receiving a bug on this.
Third - local modifications to a package.json will just be overwritten the next time the package is updated. Therefore the suggestions y'all made along that line will be ephemeral and break at some random time in the future. It's better to take this issue up with the package maintainer, and with Drupal Core.
Comment #20
iainH CreditAttribution: iainH commentedI'm going with @iamcarrico #15 as being the cleanest workaround.
@reikiman re 3: under what circumstances do you see the "scripts" element being overwritten in our theme's
package.json
? Isn't it the case that this file is part of our theme and entirely under the control of the theme developer?Comment #21
cdmo CreditAttribution: cdmo commentedI get where @jorgegc is coming from, but I think renaming the folder where npm puts packages is also hacking. I went with @iamcarrico solution because it's maybe less hack-y and quite a bit easier. Thanks for everyone's contributions.
Comment #22
DrupalHack CreditAttribution: DrupalHack commentedThis is still an issue.
I'm so glad this thread was here. I've been trying to puzzle this out for hours.
I was running a gulp app with local dependencies out of my theme folder. After running browser-sync I could access public facing pages with no trouble but any admin page timed out. No amount of cache or dns clearing would fix it. Only deleting local dependencies fixed the issue then, after reading this thread, moving the project to .npm.
I suspect the issue is triggered when drupal tries to switch to it's administration theme and is confused by the node packages.
Comment #23
tomasdev CreditAttribution: tomasdev commentediamcarrico solution is good, but doesnt work with 8.x because yml files still make drush slow. and you can't simply delete them, because the modules need them.