Clearing Cache with Browser-sync 1.3.0 Results in a Segment Fault: 11 error

Hi 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.

Thanks @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 a gruntfile.js.

Actually, no, that's not all I have to do. It's understand how hiding the gulpfile.js and the package.json files in an .npm directory affect my gulp workflow.

Will post my findings.

[update May 2015]

I'm going with @iamcarrico #15 as being the cleanest workaround.

[previously .... also works ]

This works for me:

1. Move gulpfile.js and package.json to the new "hidden" directory .npm
2. cd .npm and npm install (after having deleted theme root level node_modules directory of course)
3. edit gulpfile.js base directory for source and destination file paths.e.g. In the snippet bellow "../" were prepended to paths
4. in turn, invoke gulp command from within the .npm directory

Example directory structure for ihit theme

.
├── .editorconfig
├── .git
│   ├── HEAD
│   ├── ...
├── .gitignore
├── .jshintrc
├── .npm
│   ├── gulpfile.js
│   ├── node_modules
│   └── package.json
├── assets
│   ├── images
│   ├── js
│   └── sass
├── css
│   ├── ihit.hacks.css
│   └── ihit.styles.css
├── ihit.info
├── ihit.sublime-project
├── ihit.sublime-workspace
├── images
│   ├── logo.png
│   ├── search-icon.png
│   └── sprite.png
├── js
│   └── ihit.behaviors.js
├── php
│   ├── ihit_breadcrumb.inc
│   ├── ihit_form_search_form_alter.inc
│   ├── ihit_menu_link.inc
│   ├── ihit_menu_tree.inc
│   ├── ihit_preprocess_html.inc
│   ├── ihit_preprocess_region.inc
│   └── ihit_process_page.inc
├── research
│   └── Refills
├── screenshot.png
├── template.php
└── templates
    ├── html.tpl.php
    ├── node--image_gallery.tpl.php
    ├── node.tpl.php
    └── page.tpl.php

Head of gulpfile.js

// project-specific 
var project = {
  path: {
    sass: {
        source: '../assets/sass/**/*.scss',
        css_dest: '../css'
    }, // sass
  .
  .
  .

That is exactly the same structure that my projects have. I am glad you also found your way around the issue :-)

Yeah, 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!

I 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

For 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.

"scripts": {
    "postinstall": "find node_modules/ -name '*.info' -type f -delete"
  }

Hi @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

There 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.

For 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

thanks for #11
that helpend although i had to change it to

  "scripts": {
    "postinstall": "find node_modules/ -name '*.info' -type f -delete"
  }

You 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

@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

You can also set it in your local npm config.

This worked for me!

sudo npm config set unsafe-perm true

First - 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.

I'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?

I 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.

This 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.

iamcarrico 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.