Lerna fails on identical package names
See original GitHub issueExpected Behaviour
Being able to manage multiple packages with same name but different tag.
Background
flow-typed is a central repository for Flow library definitions, a bit similar to Definitely-typed.
We maintain hundreds or thousands of library definitions (depending how you count them) that we should like to publish in NPM.
For this task we would like to use Lerna. The problem is that one version of library (libdef) might match multiple versions of flow, and each of them should be accessible separately form NPM. Weβd like to have folders structure something like this:
βββ alasql
βΒ Β βββ alasql_v0.3.x
βΒ Β βββ flow_v0.25.x-
βΒ Β βββ index.js
βΒ Β βββ package.json
...
βββ lodash
βββ lodash_v4.x.x
βΒ Β βββ flow_v0.28.x-v0.37.x
βΒ Β βββ index.js
βΒ Β βββ package.json
βΒ Β βββ flow_v0.38.x-v0.46.x
βΒ Β βββ index.js
βΒ Β βββ package.json
βΒ Β βββ flow_v0.63.x-
βΒ Β βββ index.js
βΒ Β βββ package.json
where each index.js would be published to NPM separately. But e.g in case of lodash, it has one version (4.x.x), but multiple flow version ranges under each version. We want to define flow version ranges in PublishConfig as tags, but to have the same version 4.0.0
in this case.
Here is an example of DefinitelyTyped library definitions utilizing tags: https://www.npmjs.com/package/@types/uuid <- see versions tab.
Current Behaviour
Currently Lerna gives following error:
lerna ERR! ENAME Package name "@flow-typed/a11y-dialog" used in multiple packages:
lerna ERR! ENAME /Users/path/to/code/experimental/definitions/a11y-dialog/a11y-dialog_v5.x.x/flow_v0.25.x-v0.67.1
lerna ERR! ENAME /Users/path/to/code/experimental/definitions/a11y-dialog/a11y-dialog_v5.x.x/flow_v0.68.x-
Possible Solution
A) provide --ignore-version-check
flag or similar.
B) provide ignoreVersionCheck
as an lerna.json option
More context in flow-typed repository: https://github.com/flow-typed/flow-typed/issues/3083
Issue Analytics
- State:
- Created 5 years ago
- Reactions:2
- Comments:5 (1 by maintainers)
Top GitHub Comments
Iβm not sure about creating another issue, so Iβll add 2 cents here. A run of
npm version
results inYes, with 2 identical package names. The package is depended upon by 2 other packages. I donβt think version check works well here.
Just in case, check your global package.json and make sure you do not have duplicates under workspaces.