Two (and a half 😅) extra notes that might be helpful: 1) Using `pnpm-patch-i` package to patch dependencies with pnpm noticeable improves patching experience - this little tool creates a temp directory with a better name, automatically opens vscode and commits the patch with a single key press. Extra tip: in the temp directory, run `git init . && git add .` before making any changes to be able to preview the diff of your changes. Just don't forget to run `rm -rf .git` before committing a patch :) 2) One extra caveats of patching dependencies is that if you ever decide to migrate to a different package manager (say from npm to pnpm), you would have to tweak your patch files as well because might have a slightly different format (it's definitely different between these two - compare 9:08 and 15:07) 2.5) Use `-y` right after `npx` command to skip that annoying installation prompt 😄 Thank you for all your great, truly helpful and valuable videos.
How do you patch those packages that ship minified code? They only have a dist/ in node_modules which is minified and impossible to edit. Also how would you patch larger projects with TypeScript that requires building?
Minified: if you find the corresponding source via debugging there, otherwise fork + publish a temp NPM package under your name. Same for having TS support too etc
ooh frick, thats so cool 🤩, how did i not known about this O.O. Thx for the super cool video :)) No i don't have more excuses for anything that doesn't work XD
Yarn and Pnpm patch flows do not make sense to me. How could I test my changes and know that it is time to create a patch, if I must edit not the live version of the package, but a temporary version of it? And, unfortunately, most packages can't be patched this way anyway. Because you need to patch their sources, not their distribution package.