We have a React App which uses some components written by us and published to our internal npm repository. Our code is maintained in Bitbucket Data Center, the build is done with Bamboo and the npm repository is hosted in JFrog Artifactory. We work with feature branches and pull requests for developing new features.
It happens often that a new feature in the app, requires a change in the component. In this case, each repository (the App and the component) will have its own feature branch and pull request. Many times the component interface changes, so that the App needs the pull request version of the component and not the mainline one to build and to be tested.
The build is done exclusively by the build server, so that the bundled javascript files are not committed to git.
Let's say the component has version 1.0.0. A new feature in the App needs a change in the component. In this case, the component version will incremented to 1.0.1. We don't want to publish it to Artifactory, until version 1.0.1 is tested, but at the same time, the build of the new App version needs the changes from version 1.0.1.
Our current solution is to change the package version of the component during the build of feature branches to something like 0.<Ticket #>.<Build #>. This 0.x.x version will be published to Artifactory so that the App feature branch can use it to compile.
We use 0.x.x so that the version is never bigger than the current released version. Once the component is merged to the main branch, it will compile with the right version (1.0.1) and will be published to Artifactory again.
I find this solution cumbersome, it requires some funny build scripts, making sure that the branch name always follows some convention and teaching developers about it.
I wonder if there is a better way for managing pull requests and feature branches using npm, without having to manipulate the package.json during build time, depending if it is a feature branch or the main branch.
Sounds like you are using artifactory like a secondary version / staging for the npm package, just use npm?
I am not in devops, but have worked on a few packages, testing a package that has not been released does not sound like testing the package - what about using a beta tag npm publish --tag beta, pulling that into your app npm i package#beta then testing your application in a staging environment?
As i expect you know if you apply a tag then the tag would need to be specified to be pulled into a repo so you can use it to deter users from using that version of the package - an i believe you can delete versions later if you are dead set on not having it public.
Here is a medium article which may be helpful?
Related
I have a private npm package that is currently published to npm. The maintainer before me did not consider automated versioning, and the version is 1.0.58.
I have installed semantic-release and a small GitHub app that can be found here: https://github.com/zeke/semantic-pull-requests
My Github Action is setup properly, because when I push to main, the process goes through and reach the publishing step. However, the tags that are created started at 1.0.0, then 1.0.1, etc.
I tried creating a tag manually on the main branch at the latest merge, that tag is v1.0.58, but when I publish again, the tag that is created is still 1.0.2, etc. As such, I get an error message that says I can't publish "over" the current version.
How do I go the 1.0.59 with a fix:... commit?
Thanks everyone!
Forgot to post solution...
It seems Semantic Pull Requests did not have a proper starting point as the initial tag was created after it was linked to the repository. Uninstalling Semantic Pull Requests, adding the latest tag (corresponding to current version of published npm package) manually and reinstalling Semantic Pull Requests caused to process to go through flawlessly with semantic-release.
I'm new to the .NET Core framework and currently setting up a dashboard that uses Razor pages and some JavaScript interactions. For the few example projects I've created none of them came with a package manager from the get go, which imho is needed to keep the application maintainable. Coming from Node.js an Ruby on Rails background my default solution is NPM (or Yarn if you want).
I noticed however that Microsoft excluded Node from their base Docker images for .Net about 2 years ago (see here: https://github.com/aspnet/Announcements/issues/298).
This led me to questioning my solution to use NPM and I went looking for alternatives. I found that you can install Javascript libraries by wrapping them in Nuget packages and installing them via Nuget. But I'm hesitant to go this way as I've seen this pattern causing issues in Ruby on Rails. It adds an extra layer of maintenance and often the Ruby Gems where no longer maintained, meaning you're unable to move to the newest versions.
Then we have Libman, which is integrated into Visual Studio (https://learn.microsoft.com/en-us/aspnet/core/client-side/libman/libman-vs?view=aspnetcore-2.2) and draws packages from https://cdnjs.com, which I believe contains less packages (but according to Microsoft has everything you need). But their own blog (https://devblogs.microsoft.com/aspnet/library-manager-client-side-content-manager-for-web-apps/) says:
LibMan is not a package management system. If you’re happily using npm/yarn/(or something else), we encourage you to continue doing so. LibMan was not developed as a replacement for these tools. For example, the SPA templates (i.e. Angular and React) we ship for ASP.NET Core depend on npm and WebPack, and we have no plans to change that.
Then we're left with Bower, which is no longer an option, from https://bower.io/:
...psst! While Bower is maintained, we recommend using Yarn and Webpack or Parcel for front-end projects read how to migrate!
So I wonder, for a monolith app, is NPM or Yarn still the right choice and if so, why did Microsoft decide to exclude Node from their base images?
You mentioned LibMan which works just fine, but you need to configure it to download packages from unpkg which is a CDN for NPM and should contain everything that you can find on npm.
I need a few changes to the ra-core package of the react-admin monorepo on my productive environment.
Can I tell a lerna published module to use my own published module as a submodule instead of it's own?
It's about this package:
https://github.com/marmelab/react-admin
https://www.npmjs.com/package/react-admin
I'm about to create a PR to maybe have these changes merged into the project itself, but I can't know when it will be merged and / or whether it will be even accepted.
But unfortunately I need these changes immediately and it's okay for me to use a fork of mine until it's clear what happens to the PR.
I tried to fork a new ra-core package and use this in my package.json, but this doesn't work. Locally linking is no problem, as I can link it directly in the react-admin module, but I need it in my production build process.
So I'm wondering if there is some way to tell the module in my package.json (react-admin) which comes with it's own subpackages to use one package that I provide in the package.json instead of it's subpackage.
I'm working on 2 projects, one library project is the npm depencency of the others.
The library project is automatically published to local npm registry (nexus) by CI (Gitlab), so developers that are only working on 2nd project don't need to download library project (at least this is the welcomed solution).
However, after deleting node_modules/mylibrary and calling npm install, I've found out, that I've got... old version of the package. The library was correcly built and our nexus allows redeploy, and it works perfectly in Gitlab CI (the project gets always the actual version of library package) so it looks like something was cached locally somewhere else (not in project itself).
How to force npm to download the actual version of the package, purging local cache if necessary? Increasing the library version after each commit is not a viable solution (if it was, there would be never the concept of snapshots in maven).
Yes, I'm aware this has been asked before but the questions were asked in a manner that didn't give me the answer to find out the appropriate usage and if each package manager had exclusive packages that couldn't be found on another.
I understand that the ionic framework has these three frameworks/package managers underneath it and I can obtain the same package into my package making any of these same calls.
npm install [mypackage]
bower install [mypackage]
ionic plugin add [mypackage]
cordova plugin add [mypackage]
I also understand that they rely on each other like so.
Parent>Child [The framework above the other you would need to install the other]
npm>bower
npm>ionic
npm>cordova
npm>ionic[contains cordova]
However from what I've seen so far I don't find any packages that are exclusive to one or the other and was wondering
1. Are there some Packages/Plugins that are exclusive to one package manager?
2. Is it better to make a different call depending on workspaces?
npm- It is called as network packet manager it is just like installing a software or package from terminal without using GUI
bower-It will be used to install the required libraries in our project
cordova plugin add/Ionic plugin add these both commands are same there is no difference between them, but we are using ionic plugin add because we are using Ionic framework.
Having any queries, reply back