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.
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 inherited a monorepo with a packages folder that has every existing package. I want to add a main package that is required by my panel package. panel already exists at version 0.34.0. Seeing as I merge to my repo without publishing a new version all the time, I want to create main at 0.34.0.
I tried going into packages/main but doing npx lerna publish only wants me to do 0.34.1 so I am worried if I try to do custom 0.34.0 I will break something. I tried npx lerna boostrap but it even says it goes to root doesn't ask for me to do anything in regards to brand new package in existing project.
Do I need to create the package and bump my whole monorepo to 0.34.1 via publish to then let any existing package use it?
I use symlinks locally, but when I go to make a PR, my CI will run yarn install which (I don't think) would find the packages when reviewing the package.jsons. Therefore, I don't think Using Lerna with unpublished packages applies here? I think I need to actually publish a version that can be referenced?
Going into the new main folder and typing npm publish - and just skipping lerna, is what worked. Found that out here: https://github.com/lerna/lerna/issues/1691.
Everything went where I expected and then I could just manually update package.json files as needed that are using the new package.
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
I'm using git submodule to build and shared components between projects. The project is not in production yet, so, at this point submodule is serving well.
But I'm concerned about maintenance and deploy, would be a good idea transform it into a npm package ?
An npm package will allow fragmentation across different package versions. On the other hand, git submodules have a bit of a learning curve, and the tooling is really not that good. With git submodules, you have all the source in one folder.
If it's at all possible, I'd recommend using a plain monorepo for all projects. You may need to create build time variables (via babel plugin/s), you may need some sort of "live config" get served from the backend. I worked with git submodules for a year and I've recently worked with a project that uses npm to share code.
I would recommend using only one git submodule, for all shared code, instead of several submodules. I would strongly consider using lerna, and use your one git submodule to track lerna's packages directory. And if the team decides they don't like git submodules, you can easily make this repo a sibling git repo, instead of a submodule. However, above all this, I'd recommend using a plain monorepo.
Here's a great talk on monorepo's from Netflix: https://www.youtube.com/watch?v=VNqmHJtItCs (strong focus on discouraging npm-style packages)
Here's google's infamous monorepo talk: https://www.youtube.com/watch?v=W71BTkUbdqE
This is a great site to read to help you think about good development flows: https://trunkbaseddevelopment.com/ (it primarily advocates for the monorepo approach)
If you are developing software for different clients(different people/companies paying you for similar projects), and have some agreement that they should be at least ~80% the same, you may really enjoy using build flags to help get started on splitting functionality, but I'm sure you should very proactively keep the code around the build flags clean, and refactor into re-usable components/packages. Give each client some sort of build-flags.json. Build flags should be named for features only, which in theory can all be individually toggled. Some code may be totally custom for each project, in this case, you may want to consider using dynamic imports, but generally this is a pain point I have yet to fully cross, although I have plenty of unrefined ideas around this.
If a monorepo is just not happening, I would actually recommend using npm packages+separate repos over git submodules, assuming you can do good semantic versioning of the package. (And, yalc seems to be a good tool for linking together packages, as opposed to the standard npm/yarn link)
My findings after trying both lerna, npm workspaces and git submodules. I find it is not a case of the one vs the other.
The reason why I say this is because one can have submodules that are part of the monorepo. Doing exactly this made my development experience better as I could clone an existing project and actively develop it within the bigger project (monorepo). I could then contribute back to the cloned project once satisfied with the changes. This is something that you cannot do with npm workspaces alone. Hence my argument that it is not a case of one vs the other. They solve different problems and can therefore complement each other.
Before using npm workspaces I would use npm link all the time. npm workspaces makes this use-case of developing with multiple packages more convenient. Even when the team you work with does not use a monorepo; you could use one to develop multiple packages and test them in conjunction. Once satisfied, you can push the individual repos. This is something you cannot do with git alone.
Maybe you can think of more novel ways of combining the features of npm and git.
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.