This content originally appeared on Bits and Pieces - Medium and was authored by Eden Ella
How to modify multiple npm packages as a cohesive update and test them across projects
Say you’ve been working on a new feature or fix that affects multiple shared packages. Before releasing the changes as new versions, you want to test them in the context of the consuming projects and validate that everything works as expected.
You can easily test these changes together when projects are maintained in a monorepo. However, when projects are maintained separately, a new approach is needed. This is often the case when working with Bit.
Although Bit allows you to build and version your packages in a monorepo setup, along with their consuming projects, many opt to maintain their packages in separate repositories.
This guide explores the following workflow to test changes that affect multiple packages before releasing them:
- Modify multiple packages and group them together in a “lane” using Bit.
- Install modified pre-release packages in a consuming project.
- Automate the testing process using a CI/CD pipeline.
Modifying Multiple Packages
Before looking at how to test these changes, let’s first understand how to modify multiple packages.
When making a change that directly or indirectly affects multiple packages (Bit components), we use Bit's “lane” feature. Lanes allow you to group multiple components together in order to review, build, test, and release them as a single, cohesive update.
For example, let’s say you have two components that are used together to fetch and display content metadata from your CMS, a use-blog-list React hook and a blog-list React UI component.
You’ve decided to extend the use-blog-list hook to include a new feature that allows users to filter posts by category, and you’ve also updated the blog-list component to display the category filter.
To test these changes together, you can create a new lane that includes both components:
bit lane create add-category-filter
Visit the official Bit documentation to learn more.
The output should be similar to the following:
You can then modify the components as needed, and when you’re ready to test them together, you can snap (“commit”) the changes to the lane:
bit snap --message "add category filter feature"
The output should list the modified components in that lane, along with their pre-release (hash) versions:
To build the modified components/packages in the lane, we’ll run:
bit export
Packages are built in isolation and in an order that reflects their dependency graph hierarchy. Bit uses Ripple CI by default, but you can use your own CI if you choose to.
Installing Modified Pre-Release Packages (from a Lane)
Once you’ve built the modified packages in the lane, you can install them in the consuming project to test the changes.
As mentioned earlier, the components/packages are placed together in a “lane” named add-category-filter. To review the components, use the ‘lane’ dropdown in their respective scope on Bit Platform and select the lane name.
You can then install the modified packages in the consuming project using the hashed version of packages in that lane:
For example:
npm i @learnbit/blog-pbc.hooks.use-blog-list@0.0.0-28efcc2b49a25875b9b5617e6bc8f4ef4205e9bd
Automating the Testing Process
To automate the testing process, you can use a CI/CD pipeline that fetches the list of modified packages from the lane and installs them in the consuming project.
Since we assume the project does not maintain those packages/components and, therefore, does not have a Bit workspace, we will not use Bit CLI but rather use Bit Platform’s API https://api.v2.bit.cloud/graphql to fetch the list of modified packages and their versions (and install them using a standard package manager like npm or yarn).
query LIST_LANE_COMPONENTS($id: String!, $namespace: String) {
lanes {
id
listComponents(id: $id, namespace: $namespace) {
id
}
}
}The id parameter is the lane ID that groupes your modified packages (learnbit.design/add-category-filterin our case). The lane ID is set when creating the lane using the Bit CLI.
You can also find it in the lane title on Bit Platform. The ID is the combination of the owner/account name (learnbit), the scope name ( blog-pbc), and the lane name ( add-category-filter).
Make sure to use a Bearer token to authenticate the request. You can generate a token from your Bit Platform account settings.
Here’s a full example of how you can fetch the list of modified components from the lane using the Bit Platform API:
export async function fetchComponentsFromLane(laneId) {
const query = `
query LIST_LANE_COMPONENTS($id: String!, $namespace: String) {
lanes {
id
listComponents(id: $id, namespace: $namespace) {
id
}
}
}
`;
const variables = {
id: laneId,
};
const BIT_PLATFORM_AUTH_TOKEN = process.env.BIT_CONFIG_ACCESS_TOKEN;
try {
const response = await fetch('https://api.v2.bit.cloud/graphql', {
method: 'POST',
headers: {
'Content-Type': 'application/json',
Authorization: `Bearer ${BIT_PLATFORM_AUTH_TOKEN}`,
},
body: JSON.stringify({
query,
variables,
}),
});
const data = await response.json();
return data;
} catch (error) {
console.error('Error:', error);
}
}The data returned from this query will include the list of modified components in the lane, which you can then use to install the packages in the consuming project.
For example, see this Github Action that fetches the list of modified components from a lane and installs them in the consuming project.
- Verify Lane In Consumer - GitHub Marketplace
- GitHub - bit-tasks/verify-lane-in-consumer: Verify component changes in a (non-Bit) consumer project
In this example, the lane ID is passed as input to the workflow using Github’s UI. However, you can also trigger CI automatically when a new lane is created on the Bit Platform.
name: Verify Lane In Consumer
on:
workflow_dispatch:
inputs:
lane-id:
required: true
default: ''
permissions:
contents: write
jobs:
build:
runs-on: ubuntu-latest
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
GIT_USER_NAME: ${{ secrets.GIT_USER_NAME }}
GIT_USER_EMAIL: ${{ secrets.GIT_USER_EMAIL }}
BIT_CONFIG_ACCESS_TOKEN: ${{ secrets.BIT_CONFIG_ACCESS_TOKEN }}
steps:
- name: Checkout repository
uses: actions/checkout@v4
- name: Verify Lane In Consumer
uses: bit-tasks/verify-lane-in-consumer@main
with:
lane-id: ${{ github.event.inputs.lane-id }}
package-manager: 'npm'
Note that modified packages may not be direct dependencies of the consuming project. In this case, the project would not use the modified packages and the test would not be valid.
To solve that, either add the missing links in the dependency chain to the lane (so that the lane includes your project's direct dependencies) or force the project to use the modified packages even when they are not direct dependencies using the package manager's overrides feature.
Conclusion
Testing changes that affect multiple packages before releasing them is crucial to ensure that everything works as expected.
Using lanes in Bit, you can group multiple components, modify them, and test and review them as a single change suggestion. This makes it easier to validate the changes in the context of the consuming projects before releasing them as new versions.
Learn More
- How to Create and Publish NPM Packages
- Create and Edit Shared Modules in The Cloud
- Bit. Composable software.
How to Test Multiple Modified Packages Before Release was originally published in Bits and Pieces on Medium, where people are continuing the conversation by highlighting and responding to this story.
This content originally appeared on Bits and Pieces - Medium and was authored by Eden Ella
Eden Ella | Sciencx (2024-10-09T11:19:54+00:00) How to Test Multiple Modified Packages Before Release. Retrieved from https://www.scien.cx/2024/10/09/how-to-test-multiple-modified-packages-before-release/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.