"no such file or directory" when packaging individually.

[chrsdietz]

I have a simple setup so far regarding a particular service.

The serverless.yml is setup like so:

provider:
   name: aws
   runtime: nodejs6.10

functions:
   uploadAudio:
      handler: <handlerLcation>
      role: <aws role>
      package:
          individually: true
          include:
              - "../ffmpeg/linux_64/ffmpeg"
              - "../ffmpeg/linux_64/ffprobe"

   uploadAsset:
       handler: <handlerLocation>
       role: <aws role>

   getAsset:
      handler: <handlerLocation>
      role: <aws role>

Basically, the UploadAudio function has a dependency on ffmpeg, so I want to package this individually to keep the size of the other functions down.

However, I get this error:

Error: ENOENT: no such file or directory, open '<projectHome>/src/main/resource-server/.build/.serverless/uploadAudio.zip'
    at Error (native)
    at Object.fs.openSync (fs.js:641:18)
    at Object.fs.readFileSync (fs.js:509:33)
    at AwsCompileFunctions.compileFunction (/usr/local/lib/node_modules/serverless/lib/plugins/aws/package/compile/functions/index.js:290:24)
    at serverless.service.getAllFunctions.forEach (/usr/local/lib/node_modules/serverless/lib/plugins/aws/package/compile/functions/index.js:332:39)
    at Array.forEach (native)
    at AwsCompileFunctions.compileFunctions (/usr/local/lib/node_modules/serverless/lib/plugins/aws/package/compile/functions/index.js:332:8)
    at BbPromise.reduce (/usr/local/lib/node_modules/serverless/lib/classes/PluginManager.js:360:55)
From previous event:
    at PluginManager.invoke (/usr/local/lib/node_modules/serverless/lib/classes/PluginManager.js:360:22)
    at PluginManager.run (/usr/local/lib/node_modules/serverless/lib/classes/PluginManager.js:391:17)
    at variables.populateService.then (/usr/local/lib/node_modules/serverless/lib/Serverless.js:99:33)
    at runCallback (timers.js:666:20)
    at tryOnImmediate (timers.js:639:5)
    at processImmediate [as _immediateCallback] (timers.js:611:5)
From previous event:
    at Serverless.run (/usr/local/lib/node_modules/serverless/lib/Serverless.js:86:74)
    at serverless.init.then (/usr/local/lib/node_modules/serverless/bin/serverless:39:50)

I'm not sure why. I can also verify that the uploadAudio.zip file exists in the .build/.serverless folder during the build process. In fact, the file does get copied over to the final .serverless folder after the build throws the error.

I still get this error if I remove the include section. It seems to be an issue with the individually parameter.

It compiles and packages just fine if I don't set this to compile individually and just include the library in to the entire service. This is not ideal as the other functions do not need this library.

Is there a configuration or something that I am missing?

[EnricoPicci]

Are you using the "serverless-webpack" plugin?
Apparently there is no compatibility between "serverless-webpack" and "serverless-plugin-typescript"

[darbio]

I get the same error when I package individually. Not using serverless-webpack.

ENOENT: no such file or directory, lstat '/Users/darbio/Repositories/api/.build/functions/workers/shared/email/emails/'

The plugin doesn't check for the individual function package variable, only reading the global one from the serverless.yml file.

https://github.com/graphcool/serverless-plugin-typescript/blob/master/src/index.ts#L149-L165

It looks like the function to include packaged items only looks at the global package property.

[acon96]

It's actually an issue with https://github.com/prismagraphql/serverless-plugin-typescript/blob/master/src/index.ts#L185-L195

That operation needs to be applied to any function that is marked as being packaged individually and not just when you package the entire service as individual packages. It only checks the global package property not the per function one.

[debragail]

was this ever fixed?

[AlexStansfield]

I'm also hitting this problem. We have one really small function that we would like to package individually but still deploy to the same api gateway. Right now we running up again this. Looks like the only solution might be to restructure the project and share the api gateway, ideally we'd like to avoid this.