Use npm package fork

Hello.
Any JS developer here?

I want to use this library https://www.npmjs.com/package/ngx-daterangepicker-material but it has a bug. It seems it’s fixed in this fork GitHub - paolo-ciucci/ngx-daterangepicker-material: Pure Angular 2+ date range picker with material design theme, a demo here:

I usually do npm i <the-package>, is it possible to use the fork instead? Doing npm i https://github.com/paolo-ciucci/ngx-daterangepicker-material doesn’t work because the folder in node_modules doesn’t include the dist files.

Use yarn

yarn add https://github.com/paolo-ciucci/ngx-daterangepicker-material.git
yarn add v1.22.10
info No lockfile found.
[1/4] Resolving packages...
[2/4] Fetching packages...
[3/4] Linking dependencies...
warning " > ngx-daterangepicker-material@5.0.1" has unmet peer dependency "dayjs@^1.10.4".
[4/4] Building fresh packages...

success Saved lockfile.
success Saved 3 new dependencies.
info Direct dependencies
└─ ngx-daterangepicker-material@5.0.1
info All dependencies
├─ dayjs@1.10.6
├─ ngx-daterangepicker-material@5.0.1
└─ tslib@2.3.0
Done in 5.97s.
1 Like

Often the approach is to publish the package to npm with a different name (for example, under your own user scope or a company scope, eg. @imok/ngx-daterangepicker-material) and use that until the upstream version is fixed.

You can also use npm link (or yarn link) to use a local package version (from some folder on your computer) rather than a version from npm, but that’s frustrating to deal with if there’s multiple developers working on the project or if you want to push it anywhere.

@nem If files are missing from the repo, Yarn may not work 100% either.

1 Like

Basically what Daniel said, publishing yourself under different name is the best option for long-term because usually you need to build before release to NPM.

However, one solution I like a lot is using patch-package. Not the best solution and not maintainable at all but for a very small fix (in this case 2 lines) it should work very well. We use this in production for minor bug that upstream haven’t fixed yet / pending merge / release.

How it works is you install your package, then modify the code in node_modules, then run patch-package to allow it to look for changes and save the diff somewhere. During installation (more specifically postinstall), it will then apply that diff patch.

1 Like

Thank you all.

I published it under a different name but Angular did not recognize the module. I haven’t tried using something like @imok but it seems interesting.

I spent too many hours trying to fix that without success, so I’ll leave it as it is and removing some user functionality.

Also today I received the notice we are going to refactor the project (which started some weeks ago) because planning is meh. I’m going to look for a more complete framework than Ionic now that I have the chance.