I have come across this package https://github.com/januslo/react-native-sunmi-inner-printer
This package can only support react native version 0.61.3 and cannot support the latest version of react native.
I think the author does not maintain this package anymore. What can i do with it? I felt that i want to maintain it, but i am still new to programming.
Can anyone point me a way to maintain this package? I am worried that my apps will fail in the future if nobody maintain this package.
You can try to contact the maintainer of the repo then I see these options:
create a pull request for the repo and wait for approval
ask for ownership or rights to become a project maintainer to merge the PR yourself
fork the repo
use patch-package to patch only locally your changes
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 am trying to upgrade the react-native version to 0.60. Here how can I link manually the package. (i.e) in androind if we add the packages in Build.gradle it will link manually for that particular package.
Can any one give solution how can we acheive this in iOS link.
Is the xcodeproj will support for the 0.60 and can we able to link manually.
I have tried in the latest version of react-native 0.61.5. But it not worked for me?
Ultimately from RN0.60 onwards, manual linking is not necessary as RN has a mechanism of auto linking.
From my experience of upgrading to RN0.61, I've realized not all the library will be auto linked as expected. Reason being, the *.podspecs is not declared in your podfile. To perform this auto-linking, you need to include the 3rd party library's *.podspec within podfile. Hence during pod install, this *.podspec will tell the system where to grab the library, versions, etc.
I've previously shared a solution related to RN0.61 and *.podpsec. Maybe you can read my solution and try with it, hope it helps!
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 want to add a Card component to this module: https://snack.expo.io/#xcarpentier/gifted-chat (demo)
For example, if using onLongPress() on the Bubble Message, i want additional info to appear (right below that Bubble Message, as a small card, like Tinder Card).
How do I do that? Do I need to clone the source code and then modify it to fit what I need?
Although you are able to edit the file in your node_modules folder, it is not a great long-term solution. Why not?
The process is not consistent with using other modules
Another npm install will overwrite your changes
Your solution won't be available to someone else wanting to implement that feature
Bad Solution
If you would still like to go this route, the quickest way to go about it would be by linking it via npm. In the event this link is not available anymore, you can link a module following these steps:
In your terminal, navigate to the node module you have modified
Create a global symlink with npm link
Navigate to your app's root directory
Reference that symlink with npm link name-of-module
Again, this is not a permanent solution and should only be used for quickly testing modifications to a module.
Better Solution
Forking the repo is a good way to maintain the commits specific to that module, and you can share your modifications to the open-source community. Some reasons to fork are explained in the Github help wiki, but doing it is pretty straight-forward.
Navigate to the Github repo of the package you are wanting to change
Press the Fork button in the top right corner
npm install git+your-forked-repo-url in your project's root directory (don't forget to npm uninstall the old one)
Now, you can follow the process mentioned in the Bad Solution to locally test out changes to that package. After you're satisfied with them, you can copy those changes over to your forked repo and push them to Github (you'll want bump your version, but you may have some merge conflicts to resolve if you ever want to merge changes with the upstream repo). Then do another npm install of your repo make those changes more permanent in your node_modules folder.
If you would like to stay up-to-date with the repo you forked from, Github explains the process here.
TL;DR
Choose the Better Solution.
I found a solution in this stackoverflow answer which IMO is simpler - using patch-package and does not require forking repositories.
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