invertase
request: Melos for non-monorepos
Is there an existing feature request for this?
- [x] I have searched the existing issues.
Command
No response
Description
Since Melos has a lot of useful features that doesn't only concern monorepos, like versioning, publishing and creating changelog entries, it would be nice to be able to use it in a non-monorepo.
Reasoning
When we parse the pubspec file we can check if there is a workspace list, and if there is we continue like we do today, and if it doesn't exist we only handle ..
When the repository is a monorepo, I don't think that we should support (or at least not recommend) to have an app/package in the root, since it becomes quite messy.
Additional context and comments
The downside of using Melos in a non-monorepo is that the repository dependencies must be able to resolve together with melos in the dev_dependencies, but I think that is a fair trade-off that could be documented.
Other
- [ ] I'm interested in working on a PR for this.
This would be a great feature for those using Melos in non-monorepo setups. I shared a related use case in this comment where I use Melos primarily for versioning and changelog generation.
I'm aware of the earlier change (PR) that requires adding Melos as a local dependency to ensure consistent versions across environments. While that’s important for monorepos, could this be made optional for non-monorepo setups and/or allow specifying the Melos version directly in melos.yaml instead of pubspec.yaml?
@albinpk in Melos v7 (and on main) the melos.yaml file isn't used, there is a melos section in the root pubspec instead, so the version would have to be specified there.
I think it would be quite a lot of work to change so that the melos version is defined in there while retaining features like checking for updates, but if you want to have a go at it, go ahead!
@spydon Thanks for the clarification!
Like you mentioned, if we add Melos as a dev_dependency in the main project itself, it may lead to version conflicts between Melos’s dependencies and the project’s own dependencies.
So in that case, what would be the recommended approach for non-monorepo setups to manage the Melos version reliably?
@albinpk currently it would be to put the code inside of a subdirectory and let it have its own pubspec.
@spydon thanks, we can isolate Melos to a .melos directory, so the dev_dependencies: melos isn’t needed in the main project for both non-monorepo and pub-workspace environments. In both cases, we can use the melos: section in the root pubspec.yaml file.
To update the local Melos version, we could run pub upgrade within the .melos directory or potentially introduce a melos upgrade command to simplify that process.
Would it make sense?
@albinpk I don't think that would work, I think the pub workspace has to be defined in the root. And we also don't want to have a different structure than what is recommended for pub workspaces.
@spydon I think this wouldn’t require any structural change from how pub workspaces are set up. What I meant was only moving the Melos local dependency into a .melos directory.
For example:
Monorepo
.
├── .melos
│ ├── pubspec.lock
│ └── pubspec.yaml
├── packages
│ ├── a
│ │ └── pubspec.yaml
│ └── b
│ └── pubspec.yaml
├── pubspec.lock
└── pubspec.yaml -> root file
root pubspec.yaml:
name: _
publish_to: none
environment:
sdk: ^3.6.0
workspace:
- packages/a
- packages/b
melos:
scripts:
hello: echo 'Hello World'
Non-monorepo
.
├── .melos
│ ├── pubspec.lock
│ └── pubspec.yaml
├── lib
│ └── main.dart
├── pubspec.lock
└── pubspec.yaml -> root file
root pubspec.yaml:
name: demo
version: 1.0.0
environment:
sdk: ^3.8.1
dependencies:
path: ^1.8.0
dev_dependencies:
# No melos dependency here
melos:
scripts:
hello: echo 'Hello World'
.melos/pubspec.yaml (shared across both setups):
name: melos_workspace
environment:
sdk: ^3.6.0
dev_dependencies:
melos: ^6.0.0
So the root pubspec.yaml still defines melos: (and workspace: in monorepos), and only the Melos dependency is isolated. Does this still go against pub workspace recommendations or are there other concerns with this approach?
We just got rid of the melos.yaml file because people didn't want to have extra files in their repository, so it wouldn't be an option to have the user creating a new directory. So I think the only way forward would be to define the melos version in the root pubspec, but under the melos section, instead of under the dev_dependencies section. And then melos can read that version when starting.
The solution for this is now released in v7.1.0 https://melos.invertase.dev/configuration/overview#userootaspackage