I was using node v0.12, and just wanted to update my npm packages, however, the new version of node uses node-sass and libsass as a compiler.
I am using grunt-sass to compile my files, but ended up with a lot of errors that occur only with Libsass.
Here is an example that seems happen on sassmeister.com when using the Libsass compiler.
The solution is to add a space after the :, fine, but this is not the solution am seeking, any help please?
Here is a gist to experiment the issue and it has a weird fix tho.
http://www.sassmeister.com/gist/b8197cf0593d722f808809e8979f2ab9
Related
I'm pretty new to node.js and its package management system and its require. I'm having trouble with the following runtime error I'm getting after having installed a bunch of packages with npm install:
ERROR: Couldn't initialise framework "wdio-mocha-framework".
Error: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.9' not found
(required by <path>.../node_modules/fibers/bin/linux-ia32-v8-5.0/fibers.node)
at Error (native)
My understanding of the error is that the binary fibers.node was compiled with a newer libstdc++ than the one available at runtime.
It appears to me like the npm install did compile a fibers.node:
> fibers#1.0.13 install <path>.../node_modules/fibers
> node build.js || nodejs build.js
make[1]: Entering directory `<path>.../node_modules/fibers/build'
<snip some output, including warnings, here that I don't deem relevant>
Installed in `<path>.../node_modules/fibers/bin/linux-ia32-v8-3.14/fibers.node`
However, I see that the fibers.node that is throwing the error at runtime is not the same one as was compiled, and I assume that's the source of the problem.
Compiled:
.../linux-ia32-v8-3.14/fibers.node
Used at runtime and fails:
.../linux-ia32-v8-5.0/fibers.node
So I'm guessing and hoping that if I could convince wdio-mocha-framework to use the locally-compiled fibers.node, it would work. My questions are thus:
Would that fix it?
If so, how do I achieve that?
If not, what's the correct direction to take to further understand and fix this error? Perhaps instead of getting 3.14 to be used at runtime, I should be convincing 5.0 to be compiled at install-time? Or ... other?
Your help is most sincerely appreciated.
Update/Edit:
I think I solved this on my own, in case anyone ever finds this poor, dusty old question lying forgotten on the back of a shelf somewhere...
The problem was apparently due to multiple versions of node/node-gyp that were installed in my environment in parallel, and the build process, even though it was started with a newer version of node, was finding node-gyp in the $PATH and that's apparently what caused the old version of fibers to be built. At least, I think so.
Just had this problem recently. I managed to solve it just by uninstalling the current version of Node.JS (I had the most recent, in this case 9.5.0) and installing the recommended, in this case 8.9.4. and the issue is gone. hope this helps someone.
In my nodeJS project suddenly it give error.I do not any upgrade or changes.
When I write NPM start in command line it give that error
ERROR in ./~/css-loader?sourceMap!./~/postcss-loader!./~/sass-loader?
sourceMap&outputStyle=expanded&includePaths[]=c:/TFS/rc1/app/scss&includePaths[]
=c:/TFS/rc1/~/compass-mixins/lib&sourceMap&sourceMapContents=true!./app/scss/_toolkit.scss
Module build failed:
undefined
^
Functions may not be defined within control directives or other mixins.
in c:\TFS\rc1\node_modules\compass-mixins\lib\compass\functions\_lists.scss (line 81, column 3)
# ./app/scss/_toolkit.scss 4:14-337
I reinstall compass-mixins package but it still give same error.Then I looked _lists.scss that file in 81 line there is a code .I deleted that bu it give same error.What should I do?
#if not(function-exists(compact)) {
#function compact($vars...) {
$list: ();
#each $var in $vars {
#if $var {
$list: append($list, $var, comma);
}
}
#return $list;
}
}
I also face the similar problem. And my project is using gulp-sass and compass-mixins. As heart.cooks.mind points out that, gulp-sass is depending on node-sass. And node-sass upgrade one of its dependence libsass to version libsass 3.3.3 Delorean since node-sass 3.5.1.
However, one of libsass 3.3.3 Delorean changes is related to this problem:
'Disallow functions to be defined in control directives or mixins (#mgreter, #1550)'
Obviously, _lists.scss in compass-mixins break this rule. Seems someone raise an issue to compass-mixins and they have idea on fixing it.
Before compass-mixins release the issue fixed version, my temporary workaround is to delete node_modules/node-sass manually and npm install node-sass#3.4.2
I had the same issue,please refer to node sass release 3.5.3 is breaking build and force lock gulp-sass to use the specific node sass library using shrinkwrap and avoid using the buggy version of node sass
I am using Gulp. Version 2.3.0 of gulp-sass breaks it. Go back to Version 2.2.0 and you are all fixed.
Edit:
The real culprit is the node module inside the "gulp-sass" node module known as "node-sass". You can see inside "gulp-sass"'s package.json file that it simply pulling version greater than ^3.5.3.
Even if you go back and reinstall "gulp-sass" to 2.2.0, as I suggested earlier, the package.json file in there will still pull "node-sass" greater than ^3.5.3.
If I use the older version of "node-sass" 3.4.2 that error goes away. I don't know how to fix that in an automated way. In a pinch I was able to fix the problem by copying that folder (that is using 3.4.2) from a different project that works. Now it compiles.
Can someone smarter than me figure out a better way to accomplish this result?
What I (temporarily) did, was to install globally the node-sass v3.4.2, and then replace the gulp-sass version of node-sass (it is located within gulp-sass/node_modules) with this older one.
sudo npm install -g node-sass#3.4.2;
sudo cp -r /usr/lib/node_modules/node-sass/ /usr/lib/node_modules/gulp-sass/node_modules/;
Btw, there is a PR waiting to be merged for this. But if you want to use this today then there's a fork of the merge too.
If you want to use latter then just put compass-mixins: tjenkinson/compass-mixins in your package.json and all will be good.
Update:- There's also an npm package for the latter mentioned in the PR now
Update 2:- This should no longer be a problem with v0.12.8 now
I discovered JointsWP starter theme which looks promising.
However, I'm having troubles getting started with the sass version which I would like to use.
I did a fresh installation of wordpress, and installed the jointswp theme.
When I do npm install, it installs the dependencies.
But when I do 'gulp', I get a bunch of warnings.
Doing gulp watch and gulp styles seems to work but doing gulp vendor-js gives a "Too many errors. (67% scanned)." reply.
When I install a fresh copy of foundation 6 and use the foundation-cli, I have no problems what so ever.
Does anyone know what might be causing this?
Image of errors
Sorry for the slow response.
Those errors are normal - they're actually warnings. Your code will compile fine.
It looks like JSLint has some "issues" with how some of the Foundation JavaScript is implemented.
I've seen similar questions but no real solution that worked for me yet (most users just reinstall fibers or meteor (I'm not using meteor)).
I've added the nodejs module Sync to my nodejs 0.12.6 project. It's dependency is the Fibers module that got installed automatically with Sync. Now I wanted to load Sync via require, but it fails with the message
... /win32-x64-v8-4.3/fibers.node not found
And it's correct: In sync/node_modules/fibers/bin/ is no directory named win32-x64-v8-4.3, only win32-x64-v8-4.2 and renaming didn't solve the problem (would have been too easy)... 🙈
How can I solve this problem? How can this happen?
What is the meaning of the last number (4.3)? I guess it's windows, 64bit, Javascript v8 engine, and then? Fibers version?
Any ideas or hints?
Update:
I tried to updgrade node to 0.12.6, but nothing changed.
I found out what the 4.3 is about, it's the v8 version. Well, when running my application with electron, it is v8: '4.3.61.21'. When checking the version with node, it is 3.28. So it's maybe electrons "fault"?
Update #2:
Okay i found out that electron is based on io.js and not node. That explains the different v8 versions. But still no solution. When installing fibers with latest io.js (2.3.3), it tests the 4.2 binary, but electron requires 4.3 :(
Update #3:
Even with the same io.js version 2.3.1 as electron, it does only install the 4.2 binary.
Update #4:
Now, I've tried all three ways described at http://electron.atom.io/docs/v0.27.0/tutorial/using-native-node-modules/ (with electron version 0.29.1) - still no solution. There aren't any binaries for v8-4.3, still only the v8-4.2 ones. :(
Solution:
See my answer below. :)
At the end, i had to compile fibers on my own. As described in Update #4, i've tried it before. But node-gyp always failed and i didn't notice that i have to link to the new binary file on my own...
cd ~/my-project-root/
npm install sync
cd ./node_modules/sync/node_modules/fibers
node-gyp configure
HOME=~/.electron-gyp node-gyp rebuild --target=0.29.1 --arch=x64 --dist-url=https://atom.io/download/atom-shell
Then i've created the missing directory and moved the new binary there:
mkdir bin/win32-x64-v8-4.3
mv build/Release/fibers.node bin/win32-x64-v8-4.3/fibers.node
Now Sync works like a charm.
You need to use the electron-rebuild tool to rebuild your native module against the version of Electron you're using
Full error/warning log: http://pastebin.com/xNjC4FDr
I had problem as well when I tried to install MongoDB, I have made SO question of it but, that was only warnings, so I could ignore it. But this time it's not only warnings, but also red error.
What do I have to do? Is my Nodejs messed up because I've installed Visual Studio Tools for NodeJS in the past? Or is this normal behavior? What can I do about this, I prefer not to see errors/warnings when I install something on NPM.
The problem is that hiredis does not support Windows currently. The link to the Windows-compatible fork in the hiredis readme seems to be outdated (last commit in 8/2013 as of this writing), so you may be out of luck.
However hiredis is not required by the redis module, it's an optional dependency that just makes parsing the redis protocol faster than the pure JavaScript parser that is bundled with redis. You may see a similar thing with other modules that have optional dependencies like this. Typically if you see the module tree outline at the end of the console output, that means the module installation was successful.