One subdirectory contains serverless.yml, part of your code.
Another subdirectory contains a separate serverless.yml, more of your code.
The reason I’m asking is because we’re trying to put two serverless projects using the same library of code. One is distributed on a per-stage basis; the other is only distributed once per region, for some common resources and a little utility code that can only have one instance (listening to SQS queues, etc). Our actual setup up to now is like this:
Parent directory contains package.json, node_modules, and the serverless.yml for the per-stage distribution.
One subdirectory is our main library of code.
Another subdirectory contains a separate serverless.yml, package.json, node_modules, and more of our code.
The problem is that we’d like to refer to the main library with some of the common resources files, and webpack doesn’t package up the resources from the main node_modules well. I’ve tried finagling the webpack plugin config to no avail, so I thought I’d remove the package.json and node_modules from the subdirectory and just have one package.json, one node_modules at the parent directory level. I get error messages when I try to deploy from the subdirectory about the “missing package.json” … I can’t tell if it’s serverless itself that’s missing the package or the webpack plugin.
So before I bang my head against this any more, I thought I’d check to see if anyone else had been getting serverless to deploy by referring to a package.json and node_modules that is in the directory above the one that they’re, with or without webpack. If so, I’d love to hear what configurations I’m forgetting to do right.
The right way to do this is to vendor your shared code, and use the package management tools to manage it (i.e. npm). One feature that will probably help you is the npm link command; It will let you keep one “authoritative” copy of your library (locally) and link to it from multiple services.
Doing what you’ve outlined (i.e. incorporating the parent node_modules directory) is not a good idea, because it means that your service relies on external (to the project directory) dependencies, and not a scenario that NPM supports.
OK, thanks for your advice, Rowan. I’ll explore some more as to what is possible with the ideas you describe above. If I find a solution I’ll try to remember to post it here.
Though it does seem to me that it’s a permanent or temporary limitation of serverless or webpack, not npm. In our design our repository starts at the parent directory, and we see all of this code as one project. It’s possible that serverless and webpack running in the subdirectory defines itself as the project, and is not willing to move ahead without a package.json … though I still suspect it could be because I haven’t configured them properly. Node doesn’t seem to have restrictions against looking in a parent directory for required modules: https://nodejs.org/api/modules.html
I’ll try to learn more and improve my understanding of this situation, as I’m not an end-all expert on all these tools.
Yeah, this might be a bit different from what you’re used to if you’re relatively new to NodeJs package management.
Having a package.json in the root of your project is a common convention, but maybe not something that’s explicitly called out. npm relies on all of you dependencies being declared in a local package.json to avoid the mess that is system-installed (i.e. implicit) dependencies (which is why Ruby has bundler, and Python has virtualenv, etc).
Most of the tooling in the NodeJs ecosystem relies on there being a package.json in the root of the project e.g. Webpack relies on package.json for resolution, as mentioned in their docs.
Each Serverless Service effectively assumes it is the project you’re working on - lumping them together in a “meta-repository” is not a common practice. Do you have multiple functions in your Serverless Service? If so, I would argue it deserves its own project, but now we’re getting in to semantics The model you’re following reminds me more of an Apex project.
The model you’re following reminds me more of an