search

sass / node-sass

:rainbow: Node.js bindings to libsass
https://npmjs.org/package/node-sass
MIT License
8.5k stars 1.33k forks source link

Lambda, environment, bindings issues #2724

Closed leads closed 4 years ago

leads commented 4 years ago

I am running (well, trying to!) a AWS Lambda. I want RollupJS to do it's thing on some JS and CSS.

I am using Serverless to create the Lambda and everything works locally.

Local dev is Node 10.0.0 (using NVM) and the Lambda is on the node.js 10.x Runtime

Like I said, all works fine locally both running serverless-offline and when just executing the file directly from the command line.

However once it goes into the Lambda, it falls over. This is the error

2019-08-29T19:11:18.729Z 5a0749df-c586-4f04-b458-e20321cf35fb ERROR error: { Error: Missing binding /var/task/node_modules/node-sass/vendor/linux-x64-64/binding.node Node Sass could not find a binding for your current environment: Linux 64-bit with Node.js 10.x

Found bindings for the following environments:

  • OS X 64-bit with Node.js 10.x

This usually happens because your environment has changed since running npm install. Run npm rebuild node-sass to download the binding for your current environment. at error (/var/task/node_modules/rollup/dist/rollup.js:224:15) at /var/task/node_modules/rollup/dist/rollup.js:17213:17 code: 'PLUGIN_ERROR', plugin: 'postcss', id: '/var/task/src/css/app.scss' }

I have tried npm rebuild node-sass and redeployed, but I get the same issue. (nothing seemed to happen on the command line by the way)

I also tried npm rebuild node-sass --force and loads of npm stuff seemed to happen. But I get the same issue on redeploy.

I've seen a few issues around this and most seem to suggest running npm rebuild node-sass will fix it. Not sure if I've done it wrong, or if it's a conflict with AWS? If I do run it, what should I be looking for?

Any help?

Thanks, Tom

leads commented 4 years ago

Deleted node_modules Ran npm install Ran npm rebuild node-sass

No change but this is the output if it's useful:

Toms-MacBook-Pro:supersecretproject tom$ npm rebuild node-sass

node-sass@4.12.0 install /Users/tom/Code/supersecretproject/node_modules/node-sass node scripts/install.js

node-sass build Binary found at /Users/tom/Code/supersecretproject/node_modules/node-sass/vendor/darwin-x64-64/binding.node

node-sass@4.12.0 postinstall /Users/tom/Code/supersecretproject/node_modules/node-sass node scripts/build.js

Binary found at /Users/tom/Code/supersecretproject/node_modules/node-sass/vendor/darwin-x64-64/binding.node Testing binary Binary is fine node-sass@4.12.0 /Users/tom/Code/supersecretproject/node_modules/node-sass

leads commented 4 years ago

Solved it!

In node_modules/node-sass/vendor/ there was only a darwin-x64-64/binding.node folder/file.

From this github page I downloaded linux-x64-64__binding.node

renamed it to binding.node and created a linux-x64-64 folder and put it in there: node_modules/node-sass/vendor/linux-x64-64/binding.node

Then redeployed the lambda and all is well. I just need to remember to do that if/when I do a yarn update or similar.

saper commented 4 years ago

Yes, that is a proper fix - include all binaries for all node or platform versions you need in the deployment package

rajuashok commented 4 years ago

Is there no proper fix for this? Manually changing this file seems silly as all my developers need to now do this?

xzyfer commented 4 years ago

What is the use case for deploying node-sass to lambda? It's intended to be a development tool.

On Thu, 21 Nov 2019, 6:56 pm Ashok Raju, notifications@github.com wrote:

Is there no proper fix for this? Manually changing this file seems silly as all my developers need to now do this?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/sass/node-sass/issues/2724?email_source=notifications&email_token=AAENSWH5IRGMXQW5XONLF2DQUY5MXA5CNFSM4ISF5UM2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEZJY2Y#issuecomment-556964971, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAENSWAIICCOWMEUFXZOLOLQUY5MXANCNFSM4ISF5UMQ .

saper commented 4 years ago

@rajuashok This is always the case when the dev environment is different from the deployment platform.

rajuashok commented 4 years ago

What is the use case for deploying node-sass to lambda? It's intended to be a development tool. … On Thu, 21 Nov 2019, 6:56 pm Ashok Raju, @.***> wrote: Is there no proper fix for this? Manually changing this file seems silly as all my developers need to now do this? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2724?email_source=notifications&email_token=AAENSWH5IRGMXQW5XONLF2DQUY5MXA5CNFSM4ISF5UM2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEZJY2Y#issuecomment-556964971>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAENSWAIICCOWMEUFXZOLOLQUY5MXANCNFSM4ISF5UMQ .

Hmm good question. So I'm using email-templates (https://www.npmjs.com/package/email-templates), which, when I deploy is giving me this error:

Failed to render email { Error: Cannot find module 'node-sass' at Function.Module._resolveFilename (internal/modules/cjs/loader.js:636:15) at Module._require.o.require (/var/task/serverless_sdk/index.js:9:90239) at require (internal/modules/cjs/helpers.js:25:18) at renderSass (/var/task/node_modules/email-templates/lib/template-manager.js:119:14) at /var/task/node_modules/email-templates/lib/template-manager.js:69:22 at Promise._execute (/var/task/node_modules/bluebird/js/release/debuggability.js:411:9) at Promise._resolveFromExecutor (/var/task/node_modules/bluebird/js/release/promise.js:518:18) at new Promise (/var/task/node_modules/bluebird/js/release/promise.js:103:10) at render (/var/task/node_modules/email-templates/lib/template-manager.js:51:10) at renderFile (/var/task/node_modules/email-templates/lib/util.js:110:38) at /var/task/node_modules/email-templates/lib/email-template.js:273:32 at tryCatcher (/var/task/node_modules/bluebird/js/release/util.js:16:23) at Promise._settlePromiseFromHandler (/var/task/node_modules/bluebird/js/release/promise.js:547:31) at Promise._settlePromise (/var/task/node_modules/bluebird/js/release/promise.js:604:18) at Promise._settlePromiseCtx (/var/task/node_modules/bluebird/js/release/promise.js:641:10) at _drainQueueStep (/var/task/node_modules/bluebird/js/release/async.js:97:12) code: 'MODULE_NOT_FOUND' }

So I tried installing node-sass, but now I'm getting the wrong env error.

leads commented 4 years ago

What is the use case for deploying node-sass to lambda? It's intended to be a development tool. … On Thu, 21 Nov 2019, 6:56 pm Ashok Raju, @.***> wrote: Is there no proper fix for this? Manually changing this file seems silly as all my developers need to now do this? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2724?email_source=notifications&email_token=AAENSWH5IRGMXQW5XONLF2DQUY5MXA5CNFSM4ISF5UM2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEZJY2Y#issuecomment-556964971>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAENSWAIICCOWMEUFXZOLOLQUY5MXANCNFSM4ISF5UMQ .

I am running a rollup.js job with a lambda to generate HTML, CSS and JS which I then put in an S3 bucket.

rajuashok commented 4 years ago

Solved it!

In node_modules/node-sass/vendor/ there was only a darwin-x64-64/binding.node folder/file.

From this github page I downloaded linux-x64-64__binding.node

renamed it to binding.node and created a linux-x64-64 folder and put it in there: node_modules/node-sass/vendor/linux-x64-64/binding.node

Then redeployed the lambda and all is well. I just need to remember to do that if/when I do a yarn update or similar.

So I tried doing this exact thing but my deployer is not finding the linux version of binding.node at all. Just curious how you got yours to include the file. I'm guessing my serverless deploy function is rebuilding npm and only packaging my environments binding.node.

saper commented 4 years ago

If you are unable to upload arbitrary file with your deployment package I am afraid lambda environment might not be the best for you.

leads commented 4 years ago

Solved it! In node_modules/node-sass/vendor/ there was only a darwin-x64-64/binding.node folder/file. From this github page I downloaded linux-x64-64__binding.node renamed it to binding.node and created a linux-x64-64 folder and put it in there: node_modules/node-sass/vendor/linux-x64-64/binding.node Then redeployed the lambda and all is well. I just need to remember to do that if/when I do a yarn update or similar.

So I tried doing this exact thing but my deployer is not finding the linux version of binding.node at all. Just curious how you got yours to include the file. I'm guessing my serverless deploy function is rebuilding npm and only packaging my environments binding.node.

this is my deploy Lambda command "deploy": "babel-node scripts/copy-node-sass-vendor.js && sls deploy --stage prod" which copies the file from my local files, to the node_modules file, which is all then bundled up and used by the Lambda.

I've attached the copy-node-sass-vendor.js file (renamed to .txt here so it can attached)

copy-node-sass-vendor.txt

Hope it helps!

TaylorAckley commented 4 years ago

@xzyfer my specific use case for using node in lambda is to write out end user-generated scss that gets dynamically out and included in web authored scorm courses. Works great.