Comments (11)
By now I also feel that a project of this scale is better off releasing modules individually.
I do like the convenience aspect of "same version number all over" as a consumer, but being honest all of the projects I've seen doing this are a. constantly being worked on (allowing a fixed release schedule), b. almost never release breaking changes (or just disregard SemVer proper in some aspects) and c. do not rely on upstream dependencies too much (not tying themselves to their releases or features).
Considering Mochify will probably never grow into a hundred packages and will see fluctuating patterns of commit and release activity, I think releasing per module is a good choice. For example, imagine there is some change in the shape of the options passed to puppeteer (something got deprecated because Chrome or something) which would require a breaking change for driver-puppeteer
: would we want to not update puppeteer or would we want to needlessly release a major version for everything else? Probably neither.
The only thing I am slightly worried about is us getting the peer dep version ranges wrong on releases (how would that even work?) but I guess we'll see how that goes.
Also: if we find this to be not working well, we still have the escape hatch of "pulling a React", hoist everything to the same highest version number (potentially skipping a few versions) and switch over to the other strategy.
from mochify.js.
Regarding peer dependencies, I have previously used them with multiple major versions, like ^1.0.0 || ^2.0.0
. If one of the other dependencies requires v1, that is installed. If v2 is compatible with the rest of the tree, that is preferred.
from mochify.js.
@m90 That is correct.
from mochify.js.
Here is a suggestion how we could continue to release with @studio/changes
: javascript-studio/studio-changes#40
What do you think @m90?
from mochify.js.
How would that work for someone who's trying to publish a new version of say a driver? Would you
npm run version -- -w driver-puppeteer
from mochify.js.
I'm currently doing releases with
cd cli
npm version patch
cd ..
npm install
The version
script of each module would be changes -w
.
from mochify.js.
We can also do
npm version patch -w cli
which has pretty much the same effect as the above, afaict. The npm status bar messes up the console output though.
I didn't find any documentation about npm behavior of version
with -w
. Hopefully this is going to be improved.
from mochify.js.
npm version patch -w cli
Ah ok, now I start to understand what the PR in changes
actually does and it seems to make sense.
Would a "release every package always" workflow look much different?
from mochify.js.
Here is my view of what is good and bad about the "release very package workflow":
Good
It would be easier to generate the changelog on the top level project, or we could still try the per-module changelog with the new changes
feature.
Tagging would also be easier since the tag name could align with the version numbers of all packages. With the suggested per-module release workflow, there would be version commits like cli v1.2.3
which would be tagged cli/v1.2.3
.
Bad
The "release every package workflow" would mean that a patch in one of the drivers would cause a release of everything, also unrelated drivers, the cli
and the shared mochify
package. I'm not a fan of creating unnecessary noise in package updates. I expect the cli
and the shared mochify
package to become relatively stable and updates to happen more frequently in the the drivers.
The whole npm workspaces thing is new to me and I still consider this an experiment and there is certainly some learning required. I would vote for trying the "release each module separately" approach.
What I quite like about npm workspaces in general is that the tooling for releasing, formatting and linting can be shared between all modules via the top level package.json
. Updates in the toolchain wouldn't be reflected in the changelog of the sub-modules, which removes noise for readers. Also the package.json
of individual modules only contains devDependencies
that are acutally require
d in the module tests (to make the linter happy and to be able to migrate tests to new library versions per sub-module).
from mochify.js.
On more question for my understanding about the peer dependency handling:
In case we release a new major version of @mochify/mochify
, each driver would have to release a new version so the new major would also be allowed in its range of peerDependencies
. This release would not necessarily have to be a major release though.
Is that correct?
from mochify.js.
This whole npm workspaces situation with npm version
isn't working. npm is not creating tags and there doesn't seem to be any recent development.
So I gave up on it and moved all sub projects into own repositories in a new org:
https://github.com/mochify-js
from mochify.js.
Related Issues (20)
- Async test cases that fail end the entire test suite HOT 2
- Mochify does not work on Browserstack with Safari 12 or Firefox 64 HOT 10
- uncaught errors should be printed to stderr, not stdout HOT 6
- Support Puppeteer for Firefox HOT 6
- Support `--dumpio` option for tracing down errors with chromium
- Pass flags to Browserify HOT 3
- Update to a more recent version of mocha HOT 9
- Use Browserify 17 HOT 1
- Mochify Rewrite HOT 14
- `window._webdriver_manualPoll is not a function` on BrowserStack since 8.0.0 HOT 1
- Rewrite: Puppeteer settings HOT 1
- Rewrite: Integration tests for WebDriver
- Rewrite: Implement watch mode HOT 7
- Rewrite: Allow "external" mochify drivers
- Rewrite: Support native JavaScript modules HOT 2
- Rewrite: v1.0.0
- Rewrite: nested configuration does not get merged correctly
- Rewrite: Documentation HOT 1
- Rewrite: read spec/bundle from stdin HOT 2
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 mochify.js.