I am having two issues in compiling Sass using Gulp currently. Firstly, I set 777 permissions in my "/Library/Ruby/Gems" directory to free up some permissions errors I was getting. I'm now receiving a warning each time I run Gulp, stating the following:
gulp-ruby-sass: /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/universal-darwin13/rbconfig.rb:213: warning: Insecure world writable dir /Library/Ruby/Gems/2.0.0 in PATH, mode 040777
Second, things seem to halt in terms of Sass compilation when Gulp runs into some of the "#import" declarations in my primary SCSS file. Namely, I get the following errors:
gulp-ruby-sass: error ./screen.scss (Line 4: File to import not found or unreadable: normalize.
Load paths:
/private/var/folders/cq/_pg4s6qn59q1q5fyy5681rd00000gn/T/gulp-ruby-sass/bower_components/compass-breakpoint/stylesheets
/private/var/folders/cq/_pg4s6qn59q1q5fyy5681rd00000gn/T/gulp-ruby-sass/bower_components/susy/sass
/private/var/folders/cq/_pg4s6qn59q1q5fyy5681rd00000gn/T/gulp-ruby-sass/bower_components/normalize-scss
/private/var/folders/cq/_pg4s6qn59q1q5fyy5681rd00000gn/T/gulp-ruby-sass)
These load paths look incorrect...I've installed these components via Bower for this project specifically, so it almost seems like I need to tell Gulp/NPM to look in my project folder instead.
Any help would be greatly appreciated!
Looks like this question was just me doing a whole lot of talking to myself, but I'll share my findings with the world nonetheless.
Turns out, this is a known issue with the gulp-ruby-sass package. See:
https://github.com/sindresorhus/gulp-ruby-sass/pull/80#issuecomment-49531932
Paths specified in the "loadPath" option in my gulpfile were not relative to the gulpfile's location in the project I was working with, so it wound up looking for some Bower components in a folder where it shouldn't have, for example:
/private/var/folders/cq/_pg4s6qn59q1q5fyy5681rd00000gn/T/gulp-ruby-sass/bower_components/compass-breakpoint/stylesheets
I found that, by prepending process.cwd() to each of my file paths, they would become relative.
If you take a look at the GitHub link I added a few lines above, you'll notice this is simply a temporary workaround until this fix is implemented into the master branch of gulp-ruby-sass, so this advice will become irrelevant at some point in the near future.
Hope this helps anybody that was in a similar, puzzled situation.
* EDIT *
As for the permissions warning I was getting for gulp-ruby-sass, it turned out I just needed to run sudo chmod -R 775 /Library/Ruby/Gems/2.0.0 to recursively change the permissions in the Gems directory.
Related
This is a weird question. I'm converting an existing site to Gatsby (a Node package I installed with npm i -g gatsby-cli), and when I run gatsby develop I get an error:
Error: ENOENT: no such file or directory, stat '/home/me/.steampath'
Now the backstory here is that on Linux Steam deliberately installs a bad symbolic link called .steampath for some stupid reason. But what I can't understand is why/how running a specific Node application (Gatsby) could result in this error, which has nothing to do with my project or Gatsby ... when running other Node apps doesn't.
I've done a grep through my project directory: steam doesn't appear in any file. Similarly I grepped my environment (env | grep steam), and there's no environmental variable pointing to that file.
So can anyone answer: why does running Gatsby cause an error in a completely unrelated symbolic link sitting outside the project in my home folder?
I imagine Gatsby must be running some sort of system command, but I can't even imagine what it could run that would scan my home directory and complain about broken symbolic links.
P.S. This error comes at the end, after other errors, so it doesn't look like it's causing gatsby develop to fail so much as it's reporting the error at the end.
P.P.S. Removing the bad symlink does fix things (although I don't know what Steam will think) ... but then I get another error about another broken symlink in my home folder (I can't blame Steam for that one). So something Node/Gatsby is doing is resulting in a scan of my home dir, and a complaint about any broken symlinks found!
Once all broken symlinks are removed Gatsby works normally. So bizarre!
An answer to your question can be found here
I also had this issue today, it surfaced when one of my JS imports was
not installed (redux). Adding the dependency fixed the issue. When the
dependency was absent from the node_modules directory, something (i
didn't dig far enough) would stat my entire home directory. With the
dependency present the ~ directory was left alone.
It's related to the node resolution algorithm and although more information is not given, I believe it may be related to this
I was also quite worried when I initially saw this error.
On the production server node_modules folder is a symbolic link for continuous deployment purposes.
When I run gulp command, I got many errors like this:
Error: Unable to find a browserify-shim config section in the package.json for /home/web/www/persist/node_modules/jquery-ui/jquery-ui.js while parsing file: /home/web/www/persist/node_modules/jquery-ui/jquery-ui.js]
filename: '/home/web/www/persist/node_modules/jquery-ui/jquery-ui.js'
. . .
If I move node_modules in project folder, build process is successfull. How to solve this problem?
Answer from thlorenz (author of browserify-shim)
Linking breaks browserify and shim since your projects dependencies
are outside of your project tree. So when looking upwards these tools
can't find the package.json of your package anymore.
So don't link your node_modules folders .. it's a bad idea anyways
since you're then linked to a global in your system, i.e. it's better
to have all your deps be local to your project. Not sure what your
deployment purposes are, but to me it seems like whoever made that
decision didn't fully understand how node/npm is supposed to work.
Hello and thanks for reading,
Historically, when I ran the command:
npm install module
Module would install in the node_modules dir of the current working directory. This still happens, however, the modules that the module use, is now installing alongside the original module, so that my node_modules dir might look like:
./node_modules/module/
./node_modules/module-of-that-module/
When it used to look like:
./node_modules/module/node_modules/module-of-that-module/
I suppose it might boil down to preference, but I don't really like the sub-modules installing alongside the main module I was trying to install, as my main node_modules directory became cluttered with hundreds of random modules fast. Also it seems kind of strange for the structure to be this way if the modules of modules need different versions.
Can anyone please explain what changed here? And how I might change it back? I tried to find a solution prior to writing this, but it's unclear to me how to search around this issue or what category it falls under.
I want to use gulp on my windows machine and it actually works pretty fine, unless I try to use the created files (like pushing to github or deleting). Then it breaks, because the filepaths are too long and it seems to be a fairly common problem. https://github.com/joyent/node/issues/6960#issuecomment-45569604
I understand that the problem arises through npm's nested directories, which extend the maximal char count for Windows directories, but in my understanding there is not any solution yet.
As I see it right now I have three options:
Try to reduce the chars of npm's directories, by changing the default from 'node_modules' to 'n_m' and hope that problem ist postponed. Like suggested here:
https://github.com/joyent/node/issues/6960#issuecomment-45569604
Then it is my question, how exactly do I change the default 'node_modules' directory name?
Change my development environment to Ubuntu, which is frankly a solution I dislike, because I've never used Ubuntu.
Stop using gulp overall.
So, how do I change the default 'node_modules' directory created through npm or what solution do you actually suggest?
There is one more tricky option.
Main problem is that gulp has a lot of nested dependencies and it creates very long nested file pathes.
But if you install some of npm modules that gulp requires in your main node_modules directory gulp will not download them as nested.
Currently you have something similar to (this may be not real path you have but idea is the same):
\node_modules\gulp\node_modules\lodash.bind\node_modules\lodash._createwrapper...
If you will add "lodash.bind" module to your project's package.json as dependency it will be installed in one level with gulp and not as gulp's dependency
\node_modules\gulp
\node_modules\lodash.bind\node_modules\lodash._createwrapper
And this will shorter all urls. You will need to fix only one or two with the longest pathes and it will work.
In my project it was enough to add this dependencies: “lodash.createcallback” and “lodash.bind” to package.json to fix everything.
Take in mind that befor doing this you probably would need to clear current node_modules folder. If you are not able to do that because off too long url you can create symbolic link to temporary short file path and delete it.
I am using jasmine-node to run jasmine tests. My project has a typical structure with "spec" and "src" folders.
Inside my "HelloSpec.js" file I had:
require('../src/Hello.js');
However when I ran the tests from the project's root folder (ie, the parent folder of both "spec" and "src") with this command:
jasmine-node spec/HelloSpec.js
I got errors indicating that the required files had not actually been required. But If I changed the require statement to:
require('src/Hello.js');
everything worked fine. So it seems that the require statements were resolving the paths relative to the folder where I was executing the tests, rather than relative to their own file location. But it doesn't make sense to me that it would work like that.
How are relative paths in "require" supposed to work?
Do I need to do something to make them work the way I expected them to?
Thanks!
Usually a path from a current directory starts with a ./ which means current directory. What you have with your src/Hello.js is a path search which seems to include the project folder.
I was of the understanding that the require ./ and ../ is relative to the file that it is being required from or at least this has always worked for me. if it doesn't start with either of these then it will usually try a path search.
jasmine-node is not node which is what my experience is based on.
jasmine-node may have a diffrent path definition which is why the path search seems to work.
If its not broke don't fix it? :)
EDIT WITH CORRECT ANSWER
Problem turned out to be me being careless. I'd forgotten to do module.exports. I fixed that and now everything works the way I expected. Not sure why it was working the other way without any export or module.exports, but it was.... Anyway, if you want to edit your answer to include this comment, I'll accept it