It seems like a number of folks are quite concerned by the possibility of monorepos being suggested as the one true way to share Elm code privately. I think it’s worth taking a step back to point out that nobody has said that. I can’t speak for Evan, but all I see here is him asking for some experience reports around using Elm in monorepos. It sounds like he knows some folks who have been successful with that approach, and I have certainly heard people speak well of it, so I think it’s perfectly reasonable to ask the community to collect more information.
While I’m personally skeptical that I could get organizational buy-in for a monorepo approach at my large but not google-massive organization, I’m open to the possibility that it might not be as difficult as I think, or that it might work better than I expect. I’d be glad to hear how attempts to adopt the practice go at other organizations. In particular, I’d like to know about:
- Getting buy-in across different org structures
- The adoption process for a large organization - gradual or all at once?
- Handling shared dependencies across different products with differing release cadences.
While I can’t think of elegant solutions to some of these problems, maybe someone else can.
In the meantime, as Evan suggested here, I can experiment with building separate tooling to link dependencies as source directories. That’s great! I was already considering that approach, and I’m pretty sure it can handle about 90% of my use cases without a high investment in tooling or a need to get organizational support. I look forward to hearing how that works out for other teams as well. We can collect information about more than one approach at once!
The only thing I’d be truly disappointed to see would be a rush to add a quick fix for private packages into the compiler and package manager. I can’t stress how much I appreciate that Elm only adds features after a good deal of consideration, even if that means things are a little awkward sometimes in the short term. I recently added TypeScript to a project and it required two additional configuration files and about a dozen additional build options on top of what I already had. I don’t want that in the Elm ecosystem.