This is a bug.
Steps to reprodue:
yarn installcd packages/serverless-randomActual behavior
prod_node_modules/@org/random AND a circular reference to the module from which we installed: prod_node_modules/serverless-randomExpected behavior
@org/randomPlease mention your node.js, yarn and operating system version.
node 8.11.3, yarn 1.9.4, OSX
So you install workspace deps, then cd into specific package that participates in your workspace and attempt to install its dependencies separately. That's not how workspaces were meant to be used. Why do you do this?
@pronebird because serverless needs to upload a production only bundle of dependencies to AWS Lambda.
That's why I have to use nohoist for serverless packages.
I see. I don't think you can run yarn install inside of individual package and expect it to work the same way, because when running yarn outside of workspace it has no way to know that @org/random comes from local workspace and not from NPM registry.
What I would try to do instead is the following:
# install production deps for the entire workspace
yarn install --production --force
cd packages/serverless-random
# dupe node_modules
cp -R node_modules prod_node_modules
# optionally: cleanup .bin? if not needed
rm -rf prod_node_modules/.bin
# upload prod_node_modules to lambda
...
# clean up prod_node_modules
rm -rf prod_node_modules
# back to development
cd ../../
yarn install --force
Note that I use --force which should force yarn to reinstall all existing deps, but this could be redundant.
Thanks @pronebird. I understand where you are coming from.
Unfortunately the step # upload prod_node_modules to lambda is not as easy as it sounds: Serverless Framework is hardcoded to look at node_modules, not prod_node_modules. And it will be unable to run because serverless itself is a dev dependency, which you have now effectively removed from the workspace.
I'm not really sure if this is a yarn issue, or a serverless issue, or both.
Based on your advice I created the artifact with a shell script and told serverless to simply use that .zip file instead of generating it:
https://github.com/tommedema/serverless-mono-example/commit/e0f97a081f35b181d55a2523cb583168e685698d
However, for a simple repo with only 2 packages, this takes a whole 60 seconds on my Macbook Pro. The whole yarn install x2 takes too long to do for the whole workspace; that's why I wanted to run it only for this package.
@pronebird I am now using your workaround but it turns out that there is an issue where the workspace dependencies are ignoring the files property of their package.json. See this post for more details.
Should I close this issue and open a new issue?
@tommedema
I am not familiar with files option unfortunately. 馃槥
I am not a core contributor or something so I can't say if this issue is worth to keep since I don't have enough inside into how yarn works.
But given that yarn relies on the use of symlinks in nohoist configuration, I believe that using --modules-folder is not possible without breaking the link with the corresponding node_modules folder, at least for files under .bin.
I created an issue at https://github.com/yarnpkg/yarn/issues/6334
Most helpful comment
I see. I don't think you can run
yarn installinside of individual package and expect it to work the same way, because when runningyarnoutside of workspace it has no way to know that@org/randomcomes from local workspace and not from NPM registry.What I would try to do instead is the following:
Note that I use
--forcewhich should forceyarnto reinstall all existing deps, but this could be redundant.