A noob method of playing with Node modules

Steps to follow to update code from a node_module like d3-force directly !!

So what we get in a node_modules are the build folder that dont support HRM (hot reload module) so we have to make changes and then build that folder using the rollup module ( maybe we can use other libs also !!)

Steps:

  1. Make that change in the file that you want !!(be it debugging statements or logic change )
  2. Install the required files, using npm install and if required change the package manager from yarn to npm
  3. Then lookup to package.json and you might find a function named “prepublishOnly”
  4. Run the command npm run prepublishOnly, If the command requires the some folder , build those or remove those folders from the npm command !!
  5. Then once you fix the errors , got the errors solved , then we build this file using npm run prepublishOnly
  6. Then run the development server using the npm run dev -- --cache

This is how to rebuild a node-module !!

Github commands

ggiittcbhreacnkcohut--sbetb-ruapnscthr_enaamm-eto=origin/branch_name

or,

gitcheckout-bbranch_nameorigin/branch_name

to check the remote of branch we get,

git status -sb : helps to find the remote branch

git config pull.rebase false: makes the default git behaviour as pull and merge (your commit history is not maintained in this) git config pull.rebase true : pulls the latest commits to the branch and add your commits on top of that

M---N-A----X--B----Y-C(oyroiugrinl/omcaailn)main)

Rebase false

M---N-mA-e--r-Xg--eB-↑--c-Yo--mC-m-iMt'←yourbranchnow

Rebase True

A---B---C---X'-Y'←yourbranchnow

in one branch , we have config.json(dev) files and in another branch we have another config.json(prod), so while merging this raises merge conflict that can be easily sorted , but in PR this gets reflected so a better way to do this is for dev , use dev config , then when merging from prod use prod config,

gggiiittttccchhhoeeemnccmkkirootauuitt-smemoyr"a-iDbgrPrioRanpn/fcmuohanrirneiltattbheuipdtsatcrihhes/amtnetogmh/ebeusen"rowraiinngtiecdndeamvlfmiiybltoreuastnncehtehditenatkoowerhiritgechivhenesarweltefbbniraelaceenkdschttfoorotmmhaektehpertohoderiocgnhieann/fgmoearsinthbirsanch

Problem when working in a large team where many are working on same features

Problems:

  1. many people working on same file, potential conflict
  2. you working on a seperate feature , others working on other features
  3. you deployed branch on prod and then rebased the branch, that leads to fast-forward errors cause remote feat branch doesnt know about these rebased commits

Best way to merge branches together

Rebase : Lifts your local commits off the branch and puts them in a temporary “holding area.”
Resets your branch to match the latest commit on the origin (origin/main).
Replays your commits one by one on top of that new base.

Industry standard is to first do rebase, fix errors that come in between and jsut stage those dont commit , and continue your replay using this command : git rebase --continue that and then do squash and merge, else if no conflict comes then change this part

Rebase , Squash and Merge and then Rebase : deadly , first you rebased (nice) , then did squash and merge ( nice , and now a new commit was created that your feature branch has no idea of and then you try to do rebase ( git tries to rerun your commits over top of the new commit and results in massive conflicts ) so you start getting merge conflicts in that part.

Once a branch is squashed , retire that branch dont use that same branch again

Merge :

Keeps the commits seperately so that everything can be known like when was this started , its first commit and helps in keeping all the history --no-commit : stages all the commit but doesnt create that final merge commit.
simple merge : merges the branch and adds that final merge commit as well to it.

BEST METHOD :

MWT23TFahh..henyeeayttWDDRumhoeeeroervvsedykuefRSlArpleqtnrobu:aewaadtf:ssTdeeehhecr1s-edh.Milemctorao:DcgimeaenFpWvlseahlbanewyirtinonauerttnrshkooceush(nsmBtdotalhrnaioaieynodnda.kdksusefpdGoelofatiotokgduelerdBeveaau,etgl(ecMo5.lCep0eteafarmni,se,xseaaspdnryr.deocfhpoeiumsgsmshhii-itognsnrg)ao.lwctolhdiessttdaaoriftluyfp,esa)atup"rrNeeosfr:emralSqMuearsghe"anmdakMeesrgteh.emainbranchhistoryimpossibletoread.Itbecomesajungleoftiny,meaninglesscommits.

To solve problem 3, we need to push but with lease so use : git push --force-with-lease , this makes sure to push changes only if no one else has pushed in your branch in that time

Stashing

Using stash you save your current changes and then go back to some other branch and pop those changes there

stash push : git stash push -m '<message>' , pushes into stash stash pop : git stash pop , removes it from stash stash apply : git stash apply stash@{0/1/2/..} , does not remove the stash stash list : git stash list stash drop : git stash drop stash@{0/1/2/..} , deletes a stash manually stash clear : git stash clear , deletes everything stash untracked files as well : git stash -u stash parts of a file : git stash -p , not useful