Comments (6)
Some food for thought after reading some Lerna issues:
There's an issue at lerna/lerna#961) which suggests to split publish
and version
commands. Having such functionality would mean that one could task developers or external packages to set appropriate versions in each package.json. These versions could be then used by the publish
command to publish each package with "independent" version without overcomplicating things.
Does that sound better?
from oao.
It's now possible to skip version bumps during publish (with the --no-bump
flag). This goes in the line of what @maciej-gurban suggests: modify subpackage versions by manual means, or using other tools, and then run oao publish --no-bump
to publish to the npm registry.
Just take into account that oao determines the packages to be published by looking and the git history and determining which ones have changed since the latest tag.
I guess this issue is now solved with the new approach — but feel free to reopen if needed.
from oao.
I'm quite reluctant to add such a feature for several reasons:
- It would make oao quite complex.
- There's Lerna to support the wide variety of monorepo types out there. I would like oao to cater to the simpler use cases.
- In my experience, synchronous versioning (the only one supported in oao) is useful not only for application development (as you suggest in your post), but also for a combination of tools that are closely related together, live in the same monorepo and share similar development and publishing lifecycles (e.g. storyboard, Neutrino, etc.).
Which would be your use case, just out of curiosity?
from oao.
I suppose I have a "two in one" use case. On one hand, we want to leverage a monorepo to develop our product and its components - responsibility of Team 1, but at the same time, Team 2 and Team 3 which cannot and will not become part of that monorepo also will need to use and contribute to these components.
Some of these components will be rather standalone and not tied to our application in ways other than having the same dependencies (on React, some UI lib and such). It's not such a big deal, but like I mentioned, unless we did a breaking change, we'd like to avoid marking the release as breaking - since it's not.
In our case, we also do pretty much total CI/CD, so we never really maintain any two versions of our applications. Master is the de facto state of production, and so having a root version in root package.json
also doesn't make sense. It's different for each "component", since these can be used in other projects and will need to be versioned of course.
I realize that oao doesn't solve the "contribute to" part of the problem and we'll probably need to utilize Bit or something similar.
from oao.
I can definitely understand your concerns about complexity. To make it work, there needs to be something to derive each package version from. Some solutions use commit messages for determining changes (I think Angular team follows such pattern), others require user input to determine to what version to bump each package. First requires a non-trivial change to developer workflow, second is more error prone and quite cumbersome for multiple packages.
from oao.
Still not tried lerna for my use case. I don't remember why im not using it, but there was something.
My use case. Im thinking for a long time to merge as many as possible of all of my 300 packages in one place, for lot of reasons.
Some are coupled, others not, some uses anothers because their are just libs. And most of them definitely cant be sync versioned.
Another important thing is that I rely on full automation: publishing+github releasing on ci, following conventional-commits (angular style, for years - started with standard-version, migrated to semantic-release and finally after creating dozen of tools and apps I end up with new-release+new-release github app) and need either separate changelogs or good looking releases page.
Following the conventional-commits style (conventionalcommits.com, eg angular), and wanting monorepo, I can do fix(foo-pkg): updates
, which means that I should publish/release only foo-pkg (and others that were changed). Actually, looking ong the git status ot git diff, may be the way?
For the last couple of dayz im playing non stop with the standard-version, conventional-changelog-cli, conventional-recommended-bump and conventional-github-releaser.. but neither works. Tried dozen of different ways.
from oao.
Related Issues (20)
- Bumping dependencies on publish HOT 25
- Allow --tree in publish command
- Fixing oao publish as a yarn script HOT 2
- [docs] yarn workspaces
- Recommended workflow HOT 2
- Semantic release HOT 4
- publish cannot be ran again of npm publish fails HOT 5
- status --src argument cannot accept multiple paths HOT 2
- remove package from all submodules HOT 2
- --ignore-src doesn't like similar names HOT 2
- Publish without version bumping HOT 1
- does not work without installing npm HOT 1
- Allow package to define a folder to publish / link HOT 4
- run-script --tree reads from subpackage node_modules folder in monorepo HOT 1
- Remove `@babel/polyfill` HOT 2
- Add OTP support for publish
- Preserve nr of spaces for output package.json's HOT 1
- Yarn workspaces and --src
- Allow main as publish branch name HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from oao.