Symlinks and dependencies above service path

[dougmoscrop]

Using symlinks (e.g. npm link) is the easiest way to reproduce this - if you link in a dependency, the resolution logic inside of node core module returns the realpath. This produces a file path that is 'outside' of the service path, and it gets included in the wrong location inside the zip.

Suppose you have:

• /work/service -- where your serverless.yml is located, this has require('foo')
• /work/foo - this is your local copy of foo, and you are trying to make and test changes to it before publishing.

You npm link inside /work/foo and then npm link foo inside /work/service/, this makes /work/service/node_modules/foo -> /work/foo and for things like unit tests, it works fine.

When you go to sls package we will get the real path of foo - /work/foo/ and this results in your service.zip file having a ./foo directory in it, not ./node_modules/foo.

For the time being I am pushing a commit that detects this and throws an error, at least it will fail at package time rather than runtime.

--

This would apply to a globally installed dependency, too.

[ajmath]

I'm getting this error now when trying to package a service that uses the newrelic package.

  Error --------------------------------------------------

     A dependency was located outside of the service directory
     - at /Users/amatheny/code/trebuchet/node_modules/newrelic
     - this is unsupported and is usually caused by using
     'npm link'. See https://github.com/dougmoscrop/serverless-plugin-include-dependencies/issues/14

The only links I could find related to newrelic are all pointing within node_modules

⇒ find . -type l -ls | grep newrelic
54853924        8 lrwxr-xr-x    1 amatheny         staff                  36 Jul  7 10:10 ./node_modules/.bin/newrelic-naming-rules -> ../newrelic/bin/test-naming-rules.js
54853765        8 lrwxr-xr-x    1 amatheny         staff                  20 Jul  7 10:10 ./node_modules/newrelic/node_modules/.bin/semver -> ../semver/bin/semver

Any suggestions?

[EbenZhang]

Getting the same when using with serverless-typescript-plugin. The typescript plugin will build everything to the .build folder and create a node_modules link in the .build folder.

[dougmoscrop]

Any help would be appreciated - I will try to get to this sooner than later but I'm pretty swamped

[EbenZhang]

the error is gone after export NODE_PRESERVE_SYMLINKS=1, which you can have a try. But I didn't get the expected result. Nothing from my node_modules is included, I need to investigate further. FYI: I'm using node 8.9.1 for dev. targeting node 6.10 for lambda.

[PaulNegoescu]

Are there any updates on this thread? I'm having the same issue with serverless-typescript-plugin. I tried multiple options but I have not yet stumbled upon the right one.

[rokoroku]

NODE_PRESERVE_SYMLINKS=1 works for me. It includes dependencies within node_modules as well.

node 9.6.1 / serverless 1.26.1

[3boysdad]

I think I found the magic sauce to get error from appearing when using the serverless-typescript-plugin along with the AWS SDK. First I only installed the SDK globally. Then define the AWS-SDK like this ->

import AWS_SDK = require("aws-sdk");

Then in a function define a S3 connection like this ->

var s3Bucket = new AWS_SDK.S3(getS3Config()); console.log(s3Bucket.apiVersions);

This error will not appear.

It will appear when you define a S3 import like this ->

import S3 = require("aws-sdk/clients/s3");

And then use it like this -> var s3Bucket2 = new S3(getS3Config()); console.log(s3Bucket2.apiVersions);

[johnhaley81]

The NODE_PRESERVE_SYMLINKS=1 does not fix yarn workspaces :(

[dougmoscrop]

This should be fixed in 3.2.0