We have a monorepo setup (using lerna) to handle multiple packages. Now when some updates are made to certain packages, the version number are bumped up and published via a jenkins job that also commits back the updated version no. to the branch that was used to run the jenkins build with.
The issue we're currently facing is that when a new version is published from a certain branch say "feature/A", it would update the version of that same package from 1.0.0 to 1.0.1 in this branch. But all the other branches are still at version 1.0.0, and if a user B with branch "feature/B" tries to run a the same publish jenkins job, they see an error stating that version 1.0.1 already exists and so the publish fails.
So we're looking for a way that allows the user to run a local script or lerna command on their branch "feature/B" locally that pulls the latest version from registry and updates the version in local their to 1.0.1, so that when user B pushes this code and runs the publish job, he is able to publish 1.0.2 successfully.
An equally helpful solution would be if somehow we can ask lerna to skip already existing package version nos and just publish the next version no. i.e skip for 1.0.1 and directly go to publish 1.0.2.
Similar question to - How to manage canary version bump in monorepo with lerna from different branches
We are currently manually updating the package version nos locally when we encounter this issue which isn't ideal and we would like to automate this.
Related
After updating to latest stable version of library ngx-masonry 14.0.0 tests failed. They had release yesterday (24.10.2022.) and here is the link to their changelog: https://github.com/wynfred/ngx-masonry/blob/master/CHANGELOG.md
Basically they added Ivy build since they were using ViewEngine on older versions. I suppose that this error is connected to that migration to newer Angular compiler. On project we use Angular version 14.
After running npm i ngx-masonry#14.0.0 update was successful without any vulnerabilities.
In order for me to test it, I run ng test for my Angular application to make sure everything is fine. The failing test is basically the basic one which tests if the component is getting created. The following error was thrown in couple of components that rely on ngx-masonry library: ReferenceError: require is not defined
Since this is quite fresh issue (<24hrs old) probably more developers will run into it when they upgrade version to 14.
Link to the issue opened right now on their GitHub repo: https://github.com/wynfred/ngx-masonry/issues/98
Maybe we are missing something or this could be solved easily. :)
The owner of the library have just released 14.0.1 version which contains the fix. After you run npm i ngx-masonry#14.0.1 everything should be fine. Tests are passing as expected and app compiles successfully.
I have a continuously growing website which has automated CI/CD using github actions. The website is build in React and using jest and cypress to do the testing. As for backend i'm using Firebase. Here is the workflow:
Whenever a PR is created, github action will install the dependencies
using yarn
Create a test-build where Firebase emulators is used in order not to populate the prepod Firestore
Create a preprod build with preprod API keys and a preprod Firestore and auth
Test with jest up against the preprod build.
If everything succeed it will publish the website to a temporary url.
All PR's are merged into the developer branch, but here is my question:
It seems very cumbersome and redundant to do the same steps whenever a PR is merged into the dev branch, but as of now, all of above steps are done again, but on the newly merged dev branch. Is that the normal way to do, or is it okay to skip this build, since it has already be done in the pr-merge or the PR?
Your PR branches are tested in isolation, based on a previous dev branch (assuming that's where you forked from). Only if the PR branch was actively rebased against the dev branch, before merging, should you consider not re-running the full build on merges. Otherwise, you could run into a situation where multiple merges are happening, and the diff is clean for the individual PRs, but when put together within the dev branch, it no longer works.
It is an expo-eject project and the commands I have used after cloning the project are:
Yarn,
Yarn start,
Yarn android,
And it does not show any error but gets stuck on a same point everytime when I try to run the project.
The project runs fine on the laptops of other teammates, but I am facing this issue.
Here are the versions of the installed tools:
Nodejs 14.17.6,
Expo 4.11.0,
React-native-cli 2.0.1,
I am adding an image that shows where the project gets blocked.
This is the issue in running project.
Had the same issue, and tried #usama-alaf reply, which consisted of:
Installing the right SDK for the Android device
Linking the SDK path under project/android/local.properties
But none of the above worked for me. Digging a little deeper, I found this Github issue from Willem Horsten, where the developer states that there was a yarn.lock file on one of his Hard Drives. I'm actually running my development environment on a secondary HD, and I also had a lock file in the root of the drive, but after deleting it, nothing changed.
Here's what actually worked for me. I was running Node v12, and trying to build the project, and trying to check whether the Node version was the culprit, I did this:
Deleted my node_modules, yarn.lock, and all other lock files I could find (for some reason there was also a package-lock.json file on the project)
Since I'm using NVM, I switched to Node v15.14.0 (the latest I have installed).
Installed the dependencies again with yarn install
Ran yarn android, and the build worked this time.
I have a folder which name is project.
I use "yarn add" to install two packages (antd and antd-mobile)，both of them have a dependency which name is rc-checkbox.
antd uses "rc-checkbox": "~2.1.5".
antd-mobile uses "rc-checkbox": "~2.0.0".
After running the command, project/node_modules has a 2.0.0 version rc-checkbox folder, and project/node_modules/antd/node_modules has a 2.1.5 rc-checkbox folder.
The weird thing is no matter which one I install first, antd-mobile's 2.0.0 rc-checkbox will be installed at project/node_module. And when I run the project, antd uses the rc-checkbox which version is 2.0.0 (it is supposed to use 2.1.5) and it causes the bug.
So why would this happen? I think two packages use same another package with difference version should not impact each other.
Copy from Here
Version locking
yarn generates yarn.lock after each installation which persists ALL versions of installed packages (as you probably know package can has also dependencies and dependency can have also dependency) so it can build up infinite tree of dependencies which can lead to very bad conflicts. Let's imagine this scenario
- lodash^1
- super_module#0.0.1
- - lodash#1.0.0
- another_module#0.0.01
- - lodash#1.x.x
Imagine scenario when maintainer of another_module decides to bump lodash to breaking changes version 1.2.0 what can happen is that npm in old days could fetch 2 different instances of same library, and 2 different version which could lead to extremely weird behavior. Because as you don't have exact lock in your module (you accept any semver version ^1.x.x and ^2.x.x so that means both sub modules would satisfie your requirements but fetch different version. Yarn will lock your yarn.lock AT THE TIME OF AN ADDING new package to the project, that means when other developers on your project will checkout the project he will also have same yarn.lock and yarn will ultimately "mimic" the state of package how they were installed when you committed yarn.lock on other hands NPM just looks to the semver satisfaction and can fetch 2 different version for 2 developers (assuming that in time packages are upgrading)
I am using semantic-release with travis CI to automatically publish my package. I have two question:
My version has automatically been upgraded to v1.0.0. I want it to be something like v1.0.0-development. How can I do that?
Why my github's package.json's version not same as what has been published to npm?
My version has automatically been upgraded to v1.0.0. I want it to be something like v1.0.0-development. How can I do that?
You can't because v1.0.0-development is not a valid semantic version. Once https://github.com/semantic-release/semantic-release/issues/563 is released you will be able to use pre-release version (like v1.0.0-development.1).
Why my github's package.json's version not same as what has been published to npm?
See the first entry in the FAQ: https://semantic-release.gitbook.io/semantic-release/support/faq#why-is-the-package-jsons-version-not-updated-in-my-repository