Researching and evaluating if patch-package is a feasible tool to use.

This project was initialized with Typescript Webpack Boilerplate.

Also, from patch-package's readme:

Isn't this dangerous?

Nope. The technique is quite robust. Here are some things to keep in mind though:

• It's easy to forget to run yarn or npm when switching between branches that do and don't have patch files.
• Long lived patches can be costly to maintain if they affect an area of code that is updated regularly and you want to update the package regularly too.
• Big semantic changes can be hard to review. Keep them small and obvious or add plenty of comments.
• Changes can also impact the behaviour of other untouched packages. It's normally obvious when this will happen, and often desired, but be careful nonetheless.

For smaller DIY-type projects when you want to try things and do no harm, sure go ahead.

If you're working on a complex project which involves many contributors, has many and complex dependencies and which is used in production, I'd say no.
The drawbacks clearly outweigh the benefits.
For every dependency upgrade you do (be it major, minor or patch), chances are your patches are not working anymore. Cumbersume manual labour would be required to make the patches work again.

If you need a library to change its implementation, it's better to create an issue (maybe already a PR) on that library's GitHub page and contribute to a sustainable solution instead of a dirty quick fix.

If your requirements differ too much from what the library offers, it's better to look for a different library or create one yourself.

A starter frontend boilerplate built with:

• TypeScript
• Babel (7)
• Webpack (5)
• PostCSS
• Jest
• ESLint
• Stylelint

This also uses lint-staged for running pre-commit checks.

• Support for both TypeScript and JavaScript as needed.
• May be extended to be used with React, Vue.js, or Angular.
• Minification of TypeScript/JavaScript and CSS processed files.
• Assets optimization.
• Webpack Dev Server plugin for local development.
• Webpack Bundle Analyzer for visualising script output and usage.

• NodeJS
• npm

src
└── css
│    ├── all
│    └── styles.css
├── index.ts
public
├── assets
├── favicon.ico
└── index.html

• src
  • The entry typescript file is index.ts.
  • The helpers/set-message folder is a sample folder for how to test using Jest.
  • Local files are imported using the '@' alias. See index.ts file for example.
• scr/css
  • Add your styles here and @import them to the entry styles.css file.
• public
  • Edit the index.html in the public folder to suite your needs.
  • Replace the favicon.ico with your own icon.
• public/assets.
  • Add your assets, to the assets folder.

You may change the configuration for Webpack within the webpack folder.

Run:

  npm i

Run:

  npm run serve

This will create a server at http://localhost:9000/ or at the port number specified in the webpack/configuration/config.js file.

Automatically reloads after each file change.

Run:

  npm run build

Will output all build files into the dist folder.

Run:

  npm run test

or watch files

  npm run test:watch

Run:

  npm run lint:all

To fix all possible errors automatically run:

  npm run lint:all:fix

Run:

  npm run lint:check-types

There is no automatic fix option for TypeScript.

Run:

  npm run lint:scripts

To fix all possible errors automatically run:

  npm run lint:scripts:fix

Run:

  npm run lint:styles

To fix all possible errors automatically run:

  npm run lint:styles:fix

Run:

  npm run check-size

This will create a server at http://localhost:8888/ or at the port number specified using the -p or --port option via the cli.

MIT