179

My problem seems similar to this issue, except it happens when I run yarn install in a rails app.

When I run yarn install, it runs successfully for some time, then

../src/libsass/src/ast.hpp:1614:25: warning: loop variable 'numerator' of type 'const std::__1::basic_string<char>' creates a copy from type 'const std::__1::basic_string<char>' [-Wrange-loop-analysis]
        for (const auto numerator : numerators)
                        ^
../src/libsass/src/ast.hpp:1614:14: note: use reference type 'const std::__1::basic_string<char> &' to prevent copying
        for (const auto numerator : numerators)
             ^~~~~~~~~~~~~~~~~~~~~~
                        &
../src/libsass/src/ast.hpp:1616:25: warning: loop variable 'denominator' of type 'const std::__1::basic_string<char>' creates a copy from type 'const std::__1::basic_string<char>' [-Wrange-loop-analysis]
        for (const auto denominator : denominators)
                        ^
../src/libsass/src/ast.hpp:1616:14: note: use reference type 'const std::__1::basic_string<char> &' to prevent copying
        for (const auto denominator : denominators)
             ^~~~~~~~~~~~~~~~~~~~~~~~
                        &
2 warnings generated.
  rm -f Release/sass.a && ./gyp-mac-tool filter-libtool libtool  -static -o Release/sass.a Release/obj.target/libsass/src/libsass/src/ast.o Release/obj.target/libsass/src/libsass/src/ast_fwd_decl.o Release/obj.target/libsass/src/libsass/src/backtrace.o Release/obj.target/libsass/src/libsass/src/base64vlq.o Release/obj.target/libsass/src/libsass/src/bind.o Release/obj.target/libsass/src/libsass/src/cencode.o Release/obj.target/libsass/src/libsass/src/check_nesting.o Release/obj.target/libsass/src/libsass/src/color_maps.o Release/obj.target/libsass/src/libsass/src/constants.o Release/obj.target/libsass/src/libsass/src/context.o Release/obj.target/libsass/src/libsass/src/cssize.o Release/obj.target/libsass/src/libsass/src/emitter.o Release/obj.target/libsass/src/libsass/src/environment.o Release/obj.target/libsass/src/libsass/src/error_handling.o Release/obj.target/libsass/src/libsass/src/eval.o Release/obj.target/libsass/src/libsass/src/expand.o Release/obj.target/libsass/src/libsass/src/extend.o Release/obj.target/libsass/src/libsass/src/file.o Release/obj.target/libsass/src/libsass/src/functions.o Release/obj.target/libsass/src/libsass/src/inspect.o Release/obj.target/libsass/src/libsass/src/json.o Release/obj.target/libsass/src/libsass/src/lexer.o Release/obj.target/libsass/src/libsass/src/listize.o Release/obj.target/libsass/src/libsass/src/memory/SharedPtr.o Release/obj.target/libsass/src/libsass/src/node.o Release/obj.target/libsass/src/libsass/src/operators.o Release/obj.target/libsass/src/libsass/src/output.o Release/obj.target/libsass/src/libsass/src/parser.o Release/obj.target/libsass/src/libsass/src/plugins.o Release/obj.target/libsass/src/libsass/src/position.o Release/obj.target/libsass/src/libsass/src/prelexer.o Release/obj.target/libsass/src/libsass/src/remove_placeholders.o Release/obj.target/libsass/src/libsass/src/sass.o Release/obj.target/libsass/src/libsass/src/sass2scss.o Release/obj.target/libsass/src/libsass/src/sass_context.o Release/obj.target/libsass/src/libsass/src/sass_functions.o Release/obj.target/libsass/src/libsass/src/sass_util.o Release/obj.target/libsass/src/libsass/src/sass_values.o Release/obj.target/libsass/src/libsass/src/source_map.o Release/obj.target/libsass/src/libsass/src/subset_map.o Release/obj.target/libsass/src/libsass/src/to_c.o Release/obj.target/libsass/src/libsass/src/to_value.o Release/obj.target/libsass/src/libsass/src/units.o Release/obj.target/libsass/src/libsass/src/utf8_string.o Release/obj.target/libsass/src/libsass/src/util.o Release/obj.target/libsass/src/libsass/src/values.o
  c++ '-DNODE_GYP_MODULE_NAME=binding' '-DUSING_UV_SHARED=1' '-DUSING_V8_SHARED=1' '-DV8_DEPRECATION_WARNINGS=1' '-DV8_DEPRECATION_WARNINGS' '-DV8_IMMINENT_DEPRECATION_WARNINGS' '-D_GLIBCXX_USE_CXX11_ABI=1' '-D_DARWIN_USE_64_BIT_INODE=1' '-D_LARGEFILE_SOURCE' '-D_FILE_OFFSET_BITS=64' '-DBUILDING_NODE_EXTENSION' -I/Users/st/.node-gyp/16.0.0/include/node -I/Users/st/.node-gyp/16.0.0/src -I/Users/st/.node-gyp/16.0.0/deps/openssl/config -I/Users/st/.node-gyp/16.0.0/deps/openssl/openssl/include -I/Users/st/.node-gyp/16.0.0/deps/uv/include -I/Users/st/.node-gyp/16.0.0/deps/zlib -I/Users/st/.node-gyp/16.0.0/deps/v8/include -I../../nan -I../src/libsass/include  -O3 -gdwarf-2 -mmacosx-version-min=10.7 -arch x86_64 -Wall -Wendif-labels -W -Wno-unused-parameter -std=c++11 -stdlib=libc++ -fno-rtti -fno-exceptions -fno-strict-aliasing -MMD -MF ./Release/.deps/Release/obj.target/binding/src/binding.o.d.raw   -c -o Release/obj.target/binding/src/binding.o ../src/binding.cpp
In file included from ../src/binding.cpp:1:
In file included from ../../nan/nan.h:56:
In file included from /Users/st/.node-gyp/16.0.0/include/node/node.h:63:
In file included from /Users/st/.node-gyp/16.0.0/include/node/v8.h:30:
/Users/st/.node-gyp/16.0.0/include/node/v8-internal.h:452:38: error: no template named 'remove_cv_t' in namespace 'std'; did you mean 'remove_cv'?
            !std::is_same<Data, std::remove_cv_t<T>>::value>::Perform(data);
                                ~~~~~^~~~~~~~~~~
                                     remove_cv
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/type_traits:697:50: note: 'remove_cv' declared here
template <class _Tp> struct _LIBCPP_TEMPLATE_VIS remove_cv
                                                 ^
1 error generated.
make: *** [Release/obj.target/binding/src/binding.o] Error 1
gyp ERR! build error 
gyp ERR! stack Error: `make` failed with exit code: 2
gyp ERR! stack     at ChildProcess.onExit (/Users/st/rails/myapp/node_modules/node-gyp/lib/build.js:262:23)
gyp ERR! stack     at ChildProcess.emit (node:events:365:28)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (node:internal/child_process:290:12)
gyp ERR! System Darwin 20.3.0
gyp ERR! command "/usr/local/Cellar/node/16.0.0/bin/node" "/Users/st/rails/myapp/node_modules/node-gyp/bin/node-gyp.js" "rebuild" "--verbose" "--libsass_ext=" "--libsass_cflags=" "--libsass_ldflags=" "--libsass_library="
gyp ERR! cwd /Users/st/rails/myapp/node_modules/node-sass
gyp ERR! node -v v16.0.0
gyp ERR! node-gyp -v v3.8.0
gyp ERR! not ok 

Any ideas how to solve this? (I'm not even sure if it's a problem with xcode/node/rails/c++)

Other notes

  • /usr/bin/xcodebuild -version returns
Xcode 12.4
Build version 12D4e
  • cpp --version returns
Apple clang version 12.0.0 (clang-1200.0.32.29)
Target: x86_64-apple-darwin20.3.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

Please note: I don't code in cpp, so I have very little contextual knowledge of how to solve.

0

15 Answers 15

186

Update: Since node-sass version 6.0.1, Node 16 is supported. Updating node-sass to a version in the 6.x range solves this issue for Node 16. For other Node versions, the node-sass readme has a compatibility table for which versions of Node SASS are compatible with which versions of Node.


What you're seeing is an error during compilation of node-sass. That's a package processing your Sass/SCSS styles, which is written in C++ and only re-packaged as a JavaScript library. The fact it's written in C++ means it needs to be compiled on your device during installation (this is internally done by a tool called node-gyp, which you can spot in your error output, too).

The problem is node-sass doesn't support Node 16 as of writing this answer, see tracking issue: https://github.com/sass/node-sass/issues/3077 There's no estimate on when it's gonna support it (and that's fair, as it's a volunteer-driven project). Even if you manage to install node-sass on Node 16, I'd advice against it, as the behavior might be undefined.

The correct solution is to downgrade your Node installation to a supported version (I can see both 14 and 15 tested in their CI). If you git cloned a project and it won't install on your machine, but works for your colleagues or on the production server, it's likely the project has a different version of Node in mind too, and isn't tested on Node 16, so I'd advice against developing it on Node 16 anyway. If the project worked for you just a few days ago, but it doesn't work now, it's very likely you recently upgraded your system setup (e.g. Homebrew), which upgraded you to Node 16 (this is what happened to me and how I found this question).

You should check with the authors of the project what's the production server version of Node it runs on and install that version locally, too. As a best practice, in the future, keep the production version and your local version of Node (and yarn or npm) in sync. For managing multiple Node versions, you can use this tool https://github.com/nvm-sh/nvm

5
  • 7
    Thank you! When trying to run yarn upgrade node-sass it still led to this error for me. I had to run yarn remove node-sass and yarn add [email protected] for it to work. Commented Aug 6, 2021 at 12:50
  • yarn upgrade node-sass fails, seemingly because it wants to build assets before yarn will actually upgrade node-sass. Michael Schober's instructions didn't work for me either, hopefully someone can post the correct incantation to upgrade soon.
    – wbharding
    Commented Aug 17, 2021 at 15:47
  • 4
    I hate node-sass Commented Feb 21, 2022 at 14:19
  • 1
    Incredible that in 2022 CSS can bring mature web applications to their knees
    – duhaime
    Commented Nov 30, 2022 at 20:12
  • So this is a dependency issue. I don't understand why package managers in Node so frequently fail at resolving dependencies. They don't even recognize the issue. They just dump everything in the logs which are obviously for package maintainers. We end up digging for an error message in the huge pile of logs starting from the invention of the wheel.
    – toraman
    Commented Oct 11, 2023 at 9:42
119

Update - simple fix!

Here's an easy way to solve this that lets you keep using node 16.

  1. Delete yarn.lock
  2. Open package.json and make sure you use webpacker version 5.4.3 (which is the latest version - it won't pull in the old version of node-sass that causes this problem)
  3. Run yarn install
  4. Start your rails server and everything should be back to normal!

Here is the previous, much longer answer (in case it's still useful):

node-sass is not yet compatible with node v16

To get around this, downgrade node (e.g. to version 14) until node-sass is compatible with v16. To downgrade node using nvm, simply run:

nvm install 14

Set version 14 globally (so each new terminal windows defaults to node version 14) by running:

nvm alias default 14

Now you have node 14 installed and set as default! ..now you just need to make your app use v14.


How to make your rails app use node 14

Install node 14 (see above). Open terminal and head to your app's root directory, then:

  1. Stop your rails server if it's running
  2. Open a fresh new terminal window (so that node --version returns 14.x (not 16)
  3. Run spring stop
  4. Delete yarn.lock
  5. Remove existing node modules with rm -rf node_modules
  6. Check that node --version returns 14. If it doesn't run nvm install 14 again.
  7. Now reinstall modules with yarn install (if you don't have yarn for node 14, install it with npm install --global yarn)
  8. It should succeed!
  9. Restart your rails server, and it will work!

If you have this problem specifically on heroku, try also ensuring your webpacker is up to date:

yarn upgrade @rails/webpacker --latest
4
  • 3
    You saved my life. This is the only solution that worked for me. Thank you so much!! Commented Jun 14, 2021 at 20:46
  • Thanks for your help! Why do we check again the version at step 6?
    – sekmo
    Commented Nov 6, 2021 at 16:27
  • @sekmo It’s simply double-checking since it’s easy to install multiple different versions and lose track, but for anyone experienced with nvm step 6 is ultimately just a check and therefore is unnecessary and can be skipped
    – stevec
    Commented Nov 6, 2021 at 16:31
  • Another potentially useful solution here
    – stevec
    Commented Feb 13, 2022 at 16:58
93

Same issue, this fixes it for me:

CXXFLAGS="--std=c++17" yarn install
3
  • 3
    Could you add an explanation of what caused the issue? Commented Mar 30, 2022 at 10:25
  • 1
    Of course, those who're using do something similar CXXFLAGS="--std=c++17" npm i
    – Shreshth
    Commented Jul 27, 2023 at 13:37
  • This is the fix; on macOS it defaults to using a newer c++ compiler version which fails to compile. Commented Feb 28 at 11:25
43

Revert to the latest Node v14 LTS for using node-sass:

brew install node@14
brew unlink node
brew link node@14
node -v
spring stop

Run in your Rails project:

yarn install

PS: Node 16 has an errors with node-sass https://github.com/nodejs/node/issues/38367#issuecomment-825461899

42

Try this:

export CXXFLAGS="--std=c++17" && npm install
0
14

I was getting this error while building node-sass.

/Users/shahwarkhalid/.node-gyp/16.6.1/include/node/v8-internal.h:488:38: error: no template named 'remove_cv_t' in namespace 'std'; did you mean 'remove_cv'?

This hack solved my issue:

cd /Users/shahwarkhalid/.node-gyp/16.6.1/include/node/

open v8-internal.h file in an editor.

change remove_cv_t to remove_cv on line 488.

yarn install again and the issue was resolved.

1
  • 1
    While this may do the trick, you might be breaking things for everything else. I would advice, if going this path, to at least revert the file to the original state after a successful run of yarn install. In my case @Ulises 's answer worked: stackoverflow.com/a/70086482/1038490 Commented Jan 1, 2022 at 21:46
11

Since some of the answers to this question, a new version of node-sass (v6) has been released that fixes the issue by adding support for node 16.

In my case, Rails was depending on an older version of node-sass because of the version of @rails/webpacker I had in my package.json (4.3.0). Updating this to a version after the current release at the time of this answer, 5.4.0, resolved the problem.

2
  • Changing this version, in addition to a $ yarn upgrade resolved my issue.
    – ddavison
    Commented Jun 13, 2021 at 17:26
  • 1
    yarn upgrade @rails/[email protected] worked for me, as suggested. Commented Jun 15, 2021 at 17:29
9

I had the same issue with Node 16. Downgrading to Node 14 worked fine for me. Here's simple steps on how you can do the same (Using Homebrew):

  • Check your current node version

    node -v 
    
  • Check for available node versions

    brew search node
    
  • To unlink from current version

    brew unlink node
    
  • Install the version you want using the following command (e.g. for version 14)

    brew install node@14
    
  • Link it to the installed version

    brew link node@14
    

At the end just make sure you have the right version install using the command from the first step.

1
8

I tried to see my current version with cpp --version which gives

cpp --version Apple clang version 12.0.0 (clang-1200.0.32.29)
Target: x86_64-apple-darwin20.3.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

The compiler version is not the C++ standard version.

The former is the version of the tool, the latter is the version of the C++ standard.

All the major recent C++ compilers (I know) meanwhile do support multiple C++ standards.

The C++ standard is important if portable (standard conforming) code shall be developed – agnostic to a specific compiler. This allows to develop code for multiple platforms, compiled by different compilers. It also helps to develop with better quality – a weakness in code which may slip through (i.e. be tolerated) in the compiler of one vendor, might be complained in another.

The explicit choice of the C++ standard in a compiler is important as well:

  • The newest supported standard of the compiler might still be in an experimental state.
  • The developer may develop against a certain (older) standard (to stay compatible to other platforms where the newest C++ standard is not yet supported by the available compilers) and wants to be sure that no newer stuff may slip in.

A compiler with a certain compiler version defaults usually to a certain C++ standard. (Which one it is might be found in the doc. or online.) Nevertheless, this is not necessarily the newest supported C++ standard.

The explicit choice of the C++ standard can be done with a command line argument:

  • g++ and clang: -std= (and probably compilers of other vendors as well)
  • MSVC: /std:.

E.g. g++ -std=c++14 calls G++ forced to the C++14 standard.

It's a bit sad that this command line argument is not literally identical for all compilers / vendors. Hence, it's more convenient to define the required C++ standard in the built tool which is used. (The built tool will take care to choose the appropriate command line argument depending on the found / used compiler.)

For CMake (which I use in daily work), this is

set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(CMAKE_CXX_EXTENSIONS OFF)

(For corner cases, additional settings may be required as I once painfully found out: SO: Pointer to member variable as static member.)

OP uses yarn, I've admittedly never heard about before.

He reported that yarn install -std=c++17 solved his issue. (I tried to find some kind of doc. for this online but I failed.)

7

Similar to @murb, I had run a brew update the other day on my build box and noticed node 16 was installed. Dropping it back down to node 12 fixed the problem for me until I can update my entire build system to work properly with a newer version of node.

1
  • Can you describe the steps you followed to downgrade? Commented May 10, 2021 at 16:01
5

Upgrade to node-sass@6 which added support for Node 16, recently released

4

Perhaps not directly an answer to this problem, but I came across this question while debugging failed builds in TravisCI and caused me to push quite a few commits to fix. For me it was caused by the fact that Node 16 was released a few days ago. I noticed that I was using nvm install node in the before_script, which always defaults to the latest, instead of nvm install which actually adheres to the version specified in .nvmrc. While using an older version of something is not a long term solution; yarn install -std=c++14 already failed for me on that very line.

4

I do not know about the const auto numerator.

But when I edited the ~/Library/Caches/node-gyp/16.4.0/include/node/v8-internal.h (yours has a different directory) as shown in my terminal error, it proceeds to compilation without error.

My solution:

I renamed remove_cv_t to remove_cv as directed on the error message.

then proceed to compilation.


What I plan next after this temporary fix is to update ng xcode. Maybe it has the updated template definition as hinted in error message

template <class _Tp> struct _LIBCPP_TEMPLATE_VIS remove_cv
2

For Apple M1 chips, working way is:

sudo xcode-select --install
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.37.2/install.sh | bash
nvm install v15
nvm cache clear
1
  • 👆 What this does is 1) install XCode Commandline Tools, 2) install Node Version Manager, 3) tell Node Version Manager to install and use Node 15, 4) clear NVM's cache afterwards, which doesn't have any practical use here. NVM is a good tool for easily swapping between Node versions. You can add .nvmrc to a project to tell NVM which Node to use. Commented Oct 10, 2022 at 8:33
-5

In my case I just switched node from 12 to 10:

nvm use 10

Not the answer you're looking for? Browse other questions tagged or ask your own question.