-
-
Notifications
You must be signed in to change notification settings - Fork 10.2k
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
De-duplicate devDependencies #4362
Comments
Ya, there's a bunch of build stuff that can be de-duplicated, though I'm not terribly concerned about it right now. Just trying to get modules (and tests for them!) into the right packages right now. We can optimize the repo structure later. |
Blargh, 7e2ba75 caused some unforeseen issues. |
Actually, lerna/lerna#507 should take care of this. When that lands, let's revisit. |
Beta 35 is out, so this is ready to go: https://twitter.com/left_pad/status/826857968930992128 |
Can work on this, have a monorepo at work I maintain that needed a similar solution. |
Thanks, @cpeddecord, that would be really helpful. The work needs to happen in the lerna repo, not here. They have a fairly active Slack channel if you're interested. Please ping us if anything changes. For now, I'm going to remove this from the 4.0.0 milestone. It's inconvenient, but not a blocker for shipping v4. |
@mjackson oh interesting, I was going to move all devDeps into the root repo and out of each package. All testing/linting/building/etc then occurs in the root repo and is no longer the responsibility of the package save for outlier tasks, such as the docs site. |
@cpeddecord That works for most things except for karma, AFAIK, which doesn't work for some reason when it's like that. See #4362 (comment) |
@mjackson I've worked around it by something like this, works fine if a bit ugly:
|
@mjackson Cool, if it's re-opened I'll spend some time on this, sharing tooling etc., :) |
Thanks, @cpeddecord. That would be great :) |
Now that we're up to lerna@2.0.0, they supposedly have this fixed. Now's as good a time as any to see if it works! 👷♀️ |
If it does, I think we'll be able to drastically reduce our build times. |
started work on this over the weekend, wondering how you feel about a unified build task versus distributed. instead of |
That's kind of one of the big reasons for using lerna. They also manage concurrency for us. I'd rather not own this ourselves. |
@cpeddecord I agree with @timdorr. I'd prefer each package to have its own scripts as much as possible. That way if they differ we won't have to make exceptions for specific packages. |
I'd like to try Yarn workspaces in this repo and move away from lerna. We're not using any of lerna's more esoteric features, so it seems like workspaces would do the trick. |
Lerna should work with workspaces. It was mentioned in the 1.0 announcement. They also said to take a look at babel's transition to workspaces. There's a lot of noise in there, but it seems to be simple enough. |
If we're using workspaces, the only thing we'll need lerna for is the publish step. |
Perhaps I'm just missing seeing it in the announcement, but with workspaces can you |
Five minutes after I posted that, #5502 was opened, which uses I'm still not sure about the build step. A custom build script could work, but it might be easiest to get workspaces working first, then figure out how to drop lerna. As an aside, would it make sense to move |
Yes plz. |
Yes, I'd agree we get workspaces working first with lerna, then figure out what to do from there. Is |
For me, moving While I don't imagine most people ever need to go looking at the doc site's source, there have been issues opened when people have wanted to, but didn't know where the source was (#5440). I think that having a One other annoyance with it (and this could be removed if we dropped lerna and added a custom build) is that we are building the documentation website whenever we bootstrap the repo. That means that whenever the Travis tests are run, we are wasting time building the website. I think that it makes sense to only install the deps needed for the website when someone actually wants to run the website locally. Finally, I just took a look at the monorepos listed in that announcement and how they store their documentation website.
This topic is only partially related to this actual issue, so I'll try not to derail this any more, but I just wanted to post this food for thought. |
@pshrmn You bring up some good points. Of all those options, I like the idea of a Since having the website in a separate dir is probably going to change some of the top-level scripts and the way we install things, I'll do that work in the same commit. I tested out yarn workspaces the other day on another project and it worked really well. |
The react-router-native tests don't pass anymore on master, so I'm reverting this until we can figure out why. Re-opens #4362
I guess this is done now with #5720 👍 |
With the monorepo, each package is installing its
devDependencies
in its ownnode_modules
. For me, this led to thereact-router
folder weighing in at ~234MB. A lot of these are duplicated across packages and should be able to be moved to the rootpackage.json
. The only ones that can't, as noted by the lerna documentation are the ones that need binaries to run (i.e.,karma
).For reference, across each
package.json
each dependency is included the following number of times:The text was updated successfully, but these errors were encountered: