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
Related
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?
I have a monorepo (Nx Workspace) that has many libraries that were generated with #nrwl/js. These libraries depend on each other. They are small utility libraries that I intend to publish on NPM as separate packages.
According to Nx docs:
#nrwl/js is particularly useful if you want to
Create framework agnostic, just plain TypeScript libraries within an existing Nx workspace (say to use in your React, Node or Angular app)
Publish TypeScript packages to NPM
Yet, I now realize that the build command associated with #nrwl/js does not take into account a library's dependencies on other libraries in order to include them as peerDependencies into its publishable package.json. It also looks like it is making just a simple commonjs build that would be compatible with node.js but not with browsers.
I know that #nrwl/angular takes care of all that stuff for you when you build a library with it if you had marked it as publishable. My question is how do I get the same behavior but for a library that is not meant for Angular but for general purpose Javascript use in any framework or environment.
It's still early in development so if a solution to my problem would involve regenerating the libs using some other Nx generator, it wouldn't be too much of a hassle for me to do so, and I'd consider it.
Edit
I have since changed the build executor to #nrwl/node, which has the buildable and publishable options and behave the way I need.
I believe that #nrwl/js will eventually gain that ability but as of 2022-01-05 it didn't have it. For now, someone looking to publish libraries on NPM probably should use #nrwl/node to generate his new library projects and not #nrwl/js
If you want to publish a NPM package as a "universal package" to be consumed by Node.js and the browser, you would need to build it as UMD, to cover most consumer environments.
Though modern browsers support ES modules (import and export), you might need extra setup steps to consume them.
I am trying to write my first set of npm libraries for a large, distributed application and am running into problems around how to manage dependencies. Npm has the concept of "dependencies" and "peerDependencies".
From what I read, peerDependencies are needed when you want to write a "plugin" where the consuming application is already expected to have the dependency installed on their end. For example, this might be building a plugin for webpack.
Then there are regular dependencies needed at runtime by a library. In my scenario, I am trying to write a library to abstract Authentication and Authorization away from the consuming application. This new library (lets call it #myapp/auth) has a dependency on the #auth0/angular-jwt library as it uses it to deal with JWTs. I want this library to be completely abstracted away from the consuming application and therefore not force that consuming application to install it manually.
With that said, it sounds like I need to add #auth0/angular-jwt to dependencies in my library and then add it to the whitelistedNonPeerDependencies which allows it to build.
This confuses me because the ng-packagr docs say that we should always use peerDependencies when possible. If this is the case, then why when you install a larger library like express, you simply run npm install express --save and you get ALL of the dependencies of express without manually installing each one.
What is the proper way to include package dependencies in a custom library that you do not want the consuming application to install themselves?
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'm trying to develop a modification to an existing react native library (the library in question is this one, although hopefully the answer to my question will be generally applicable to any library development work. I have an existing application that I would like to use with a modified version of this library. I'm not quite sure how I can set this up so that the library can coexist with the app and both build processes run correctly when the library is modified. I'm happy to run a command to update the app when the library changes, although I'd like to avoid that if possible. In case it's relevant, I'm working on a Mac.
Things I've tried:
Cloned the existing library into a parent directory of my app (so they're project/myapp and project/react-navigation-tabs)
Then used npm link ../react-navigation-tabs from the app directory, which appeared to succesfully set up the link, but when I tried to test the app, the react native packaging server complained that importing "react" was an ambiguous reference (because both project/myapp/node_modules/react and project/react-navigation-tabs/node_modules/react existed)
Removed the link produced in the last step and tried npm install ../react-navigation-tabs instead. This again apparently succeeded, but then the react native packaging server complained that it 'couldn't find preset "react-native" relative to directory "project/react-navigation-tabs"'. The preset in question is installed in the project/myapp/node_modules directory, but it seems that the packager expects it to be installed in both locations.
So:
Is there any way of persuading npm to only install the necessary libraries in one location and share them? Or alternatively install the development dependencies in both locations?
Is there another way of organising the project that will allow me to perform the updates I need without needing to install dependencies in two separate locations? This is complicated by the fact that the library in question will (presumably) need transpiling before it can be used.