Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

--modules-folder with yarn workspaces installs itself #6293

Closed
tommedema opened this issue Aug 21, 2018 · 7 comments
Closed

--modules-folder with yarn workspaces installs itself #6293

tommedema opened this issue Aug 21, 2018 · 7 comments
Assignees
Labels

Comments

@tommedema
Copy link

This is a bug.

Steps to reprodue:

Actual behavior

  • two dependencies are installed: prod_node_modules/@org/random AND a circular reference to the module from which we installed: prod_node_modules/serverless-random

Expected behavior

  • prod_node_modules should only contain dependency @org/random

Please mention your node.js, yarn and operating system version.
node 8.11.3, yarn 1.9.4, OSX

@ghost ghost assigned rally25rs Aug 21, 2018
@ghost ghost added the triaged label Aug 21, 2018
@pronebird
Copy link

pronebird commented Aug 21, 2018

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?

@tommedema
Copy link
Author

@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.

@pronebird
Copy link

pronebird commented Aug 22, 2018

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.

@tommedema
Copy link
Author

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:

tommedema/serverless-mono-example@e0f97a0

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.

@tommedema
Copy link
Author

@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?

@pronebird
Copy link

pronebird commented Aug 30, 2018

@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.

@tommedema
Copy link
Author

I created an issue at #6334

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants