Running lerna bootstrap does not install all dependencies #1457
Comments
|
This is a serious issue which happens on Node |
|
@xpepermint What ended up working for us was creating a custom js bootstrap script and executing that using The script is Replace And then in my root package.json I added an npm script: |
|
Thanks @scottmcpherson! I also came to this simple workaround: So the |
|
I am also having this issue, but I'm having trouble determining exactly which package is the issue. |
|
@lucasowens I would suggest posting your terminal output along with your comment. Maybe there's something there that could help? |
|
Thanks for the reply @scottmcpherson! Here is the output when I run The second time I run it, it works as expected. When I run Again it works successfully the second time I run it. It seems that this is somehow related to Any help appreciated! |
|
I literally can't debug without an actual reproduction. Telling me what your tree looks like is worthless without the actual contents of the package.json files. |
|
My issue seems the same, quite hard to share.
Doing
@evocateur does this mean that the external dependencies of the linked packages will not be installed? |
|
A local sibling’s dependencies are only installed under that module, and symlinked into local dependents. All external top-level dependencies of a given local package are always installed.
… On Jul 3, 2018, at 08:25, StrahilKazlachev ***@***.***> wrote:
My issue seems the same, quite hard to share.
B depends on A.
packages
A - all is fine
B - not fine, A dependencies are not installed
Doing lerna exec -- npm i && lerna link does what I want.
From bootstrap description
npm install all external dependencies of each package.
@evocateur does this mean that the external dependencies of the linked packages will not be installed?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
@evocateur Do I understand correctly that when using |
|
If you’re exploiting flat resolution to access a transitive dependency, you probably shouldn’t be. I don’t recommend bootstrap, anyway, preferring relative file: specifiers.
… On Jul 3, 2018, at 09:14, StrahilKazlachev ***@***.***> wrote:
@evocateur Do I understand correctly that when using bootstrap a local sibling external dependencies will stay "under" it(local-pkg-B/node_modules/local-pkg-A/node_modules/ext-dep-1) - loosing the flat structure in local-pkg-B/node_modules I would normally get with npm install?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
I just wanted to mention that this error disappeared for me and I'm not sure why. |
|
@evocateur The problem that I ran into while using file specifiers when designing our front-end was that we have multiple core packages that are reused across four clients. They are all in the same mono repo. And the core packages are all started and built with webpack. When we use the file specifiers, we lost live reload, because symlinks were no longer pointing to the original packages. That made file specifiers unusable for our use case. Have you ran into this issue? |
|
I don’t build packages with Webpack, but I’ve had no difficulty with Webpack-based applications watching changes from Rollup-watched package output.
… On Jul 15, 2018, at 07:33, Scott McPherson ***@***.***> wrote:
@evocateur The problem that I ran into while using file specifiers when designing our front-end was that we have multiple core packages that are reused across four clients. They are all in the same mono repo. And the core packages are all started and built with webpack. When we use the file specifiers, we lost live reload, which made file specifiers unusable for our use case.
Have you ran into this issue?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
This problem was fixed for our project by changing our "packages" path to include two asterisks instead of one. I just happened to get lucky on this one: UPDATE: spoke a little too soon I guess, I get different results with successive runs of |
ReproI created a Docker container with instructions how to reproduce the issue: silvenon/lerna-bootstrap-issue. You can check out the failing ( |
|
Hey ho,
Workspace config: Directory layout: Webpack config: Log: |
|
Same issues for us. Banging my head against a wall. Works fine on my Mac. Causing me issues on remote Ubuntu server or in a docker container. |
|
@TheAifam5 @elie222 what is your Lerna configuration ( |
I think I should open a new issue, for webpack-only related stuff. |
|
Maybe, but it seems like the |
|
@silvenon but what I seen, webpack transpiles to the "server.js" and is usable, but the error messages about missing dependencies is annoying. services/webpack.common.ts and every subproject in |
|
Nevermind, I found the problem, for my case: services/webpack.common.ts |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
|
@marschhuynh I set to below, but still |
|
I had the same issue and the root cause was that some packages were not listed in the root package.json file (probably because they were not added using // root package.json
{
(...)
"dependencies": {
"@repo/package-name": "file:packages/package-name",
(...)
}
} |
|
so.. is there any solution for this problem? 😢 |
|
|
|
I ended up adding a "scripts": {
...
"bootstrap": "lerna bootstrap && lerna exec npm install",
...
}This way, I get to do my normal npm install and once it finishes, I will execute NOTE: Making this to be in the |
|
@evocateur I face this issue when lerna is part of my |
|
This fixed the issue for me. I have a devDependecy that Lerna was ignoring because I had the NODE_ENV in production
|
|
best solution？ |
|
In my way, update root package.json like this "scripts": {
"install": "lerna exec -- yarn install",
"build": "lerna exec -- yarn build"
},So, I just run I don't know is this the right way to do this. |
|
Have the same issue in ci/cd. It can't find dependencies in on folder that have dependencies from other folder in packages/* :/ |
|
This is actually the exact issue: #1457 (comment) I globally set |
JamesHenry
added
the
scope: package management
|
Problem still exist on Lerna 5.1.8. I tried the workaround but We can't believe in the continuation of such a bug |
|
For me, |
|
@ericsvendsen solution worked, thank you!
|
|
For us, it was specifically Heroku that failed our builds. That's because they set We ended up changing our to: |
|
In my particular instance after migrating to node version |
|
After a lot of trial & error, this worked for me: lerna.json top level package.json Run: (lerna v5.5.4, node v16.17.0, npm 8.15.0) |
|
Hi Folks 👋 Please take a look at our published roadmap for Lerna v7 here: #3410 One of the key items covered at length on there (please do read it for full context) is that now that we find ourselves in late 2022, it no longer makes sense for lerna to supplement package management concerns (such as installation, boostrapping, linking etc) which are covered reliably for monorepo workspaces by the three main package managers: npm, yarn and pnpm. If you have any specific concerns please do join in on that discussion, and provide as much context as possible. Many thanks 🙏 |
and others
Expected Behavior
When running
lerna bootstrapall dependencies should be install in packages.Current Behavior
If I run
lerna bootstrapand then runlerna startto start all my clients and packages, I get the following error:If I cd into
packages/raisal-ui, and runyarn, I get the following error:But if I run yarn one more time, everything installs in raisal-ui and I can then run
lerna run startand everything starts fine.Possible Solution
Install all deps or provide logs to debug
I have the following setup:
lerna.json
{ "lerna": "2.5.1", "packages": [ "clients/*", "packages/*" ], "npmClient": "yarn", "version": "2.1.13" }Your Environment
lerna --versionnpm --versionyarn --versionnode --versionThe text was updated successfully, but these errors were encountered: