Use local lerna if available#1122
Conversation
closes lerna#138 BREAKING CHANGE lerna now prefers installs resolvable relative to the current working directory. For situations where a global install was used and an outdated lerna version is present in the node_modules folder, this might cause breakage. The issue can be resolved by installing a lerna version that fulfills the version requirement in lerna.json
marionebl
force-pushed
the
feat/use-local-lerna-if-available
branch
from
cd55ee6 to
5af9075
Compare
| @@ -1,4 +1,6 @@ | |||
| #!/usr/bin/env node | |||
| "use strict"; | |||
| const resolveCwd = require("resolve-cwd"); | |||
There was a problem hiding this comment.
I like the (more recent) import-local pattern, which encapsulates the tricky stuff for us:
const importLocal = require("import-local");
if (importLocal(__filename)) {
require("npmlog").verbose("cli", "using local version of lerna");
} else {
require("../lib/cli")().parse(process.argv.slice(2));
}| it("should throw without command", async () => { | ||
| try { | ||
| await bin([]); | ||
| fail(`Expected an exception, but it didn"t throw anything`); // eslint-disable-line |
There was a problem hiding this comment.
Where does fail come from? Seems a little odd to templatize a string that isn't interpolated.
There was a problem hiding this comment.
fail is exposed by jasmine. I changed those to match the jest recommendations: https://facebook.github.io/jest/docs/en/tutorial-async.html#async-await
There was a problem hiding this comment.
Ah, that's why I didn't recognize it. I really wish we could upgrade to Jest 21, but something in Jest 20 broke how we run the integration tests...
|
So, about the "breaking change"-ness... I don't see this change as breaking for existing calls from npm scripts, which is (especially in CI) by far the most common usage? I agree that it does constitute a very different flow for those that call I suppose I should suck it up and sketch out a 3.0 milestone, bundling a few more breaking changes (#174, ...?). |
|
Yeah, scratched my head quite a bit on categorizing this, too. I tend to play it safe with semver and mark changes as breaking as soon as there is potential breakage, especially in uncommon usage scenarios (e.g. global installation, even on CI). My personal approach to major releases is to handle them in no special way, so I'd release this without waiting for other changes. Def. your call though. |
|
If people using lerna as a CLI with some API and you breaking this API then it's breaking. If you don't breaking this API — then it's not. upd: Same for CI, btw. |
|
This thread has been automatically locked because there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
3 participants
Description
This will change the CLI behaviour to use
lernafrom the nearestnode_modulesrelative toprocess.cwd()if available.Motivation and Context
package.jsonHow Has This Been Tested?
Types of changes
Checklist:
Breaking Change:
lerna now prefers installs resolvable relative to the current working directory.
For situations where a global install was used and an outdated lerna version
is present in the node_modules folder, this might cause breakage.
The issue can be resolved by installing a lerna version that fulfills the version
requirement in lerna.json