Removal of Homebridge dependency

[theimo1221]

Describe The Problem:
Missing module homebridge-plugin-utils

node_modules/unifi-protect/dist/index.d.ts:8:26 - error TS2307: Cannot find module 'homebridge-plugin-utils' or its corresponding type declarations.

8 export { Nullable } from "homebridge-plugin-utils";

To Reproduce:

I tried using this in https://github.com/Hoffmation/Hoffmation-Base which uses Typescript as well.

[theimo1221]

Shall I open a PR moving the utils module to normal dependencies?

[theimo1221]

I did some further inspecting.
Adding homebridge-plugin-utils I'd need homebridge too:

node_modules/homebridge-plugin-utils/dist/service.d.ts:1:59 - error TS2307: Cannot find module 'homebridge' or its corresponding type declarations.

1 import { HAP, PlatformAccessory, Service, WithUUID } from "homebridge";

So I'd highly appreciate if we could separate this from homebridge, as if I understand it correctly thats the main purpose of unifi-protect vs https://github.com/hjdhjd/homebridge-unifi-protect

[theimo1221]

Once this is complete I can do it in unifi-access as well🙂

[hjdhjd]

Dependencies are a fact of life in the node package world. 😄 I have no plans to remove the dependency on my utility library - it explicitly exists to reduce duplication across a variety of things I do, and will continue to build into my libraries in the future. Your issue, and the PR to resolve it, explicitly create more redundancy and maintenance issues for me - the package author, creator, and maintainer. That’s not okay. 😄

TL;DR: this behavior is by design and not going anywhere.

[theimo1221]

Hello @hjdhjd,

While I understand the intention to reduce maintenance by outsourcing e.g. utils, those still should not be a complete truckload but rather compact.

If I understand you correctly this should be independent of home bridge/home bridge-unifi-protect.

I have been occasionally asked if I would consider packaging the core API library separately from the plugin so that other open source projects can take advantage of the work that's been done here to understand and decode the UniFi Protect API.

So the main problem here might be your utils library not being split correctly:

• Generic utils (like your nullable type)
• Homebridge utils which could have homebridge as a dependency

Which could result in following usage:

• Generic utils: almost no dependencies
• Unifi-protect: depends on generic utils and others
• Homebridge utils: depends on generic utils and homebridge
• Homebridge unifi protect: depends on generic utils, unifi protect, homebridge utils, homebridge and others

Especially if you consider 2 of those 3 types you use from the library are from a different library as well.

The error I mentioned opening this issue can of course be prevented at api consumer with e.g. theses options:

1. Set skipLibCheck: true in ts.config (see https://www.typescriptlang.org/tsconfig/#skipLibCheck )
2. Add homebridge and homebridge-utils as dev-dependencies in the own package.json

Both of these options should (in my opinion) not be "forced upon" the consumer of a library...

Please do not missjudge my comments as negative/harsh but rather constructive feedback.

I'm an open source developer myself with a comparable set of libraries (Hoffmation-Base, Hoffmation-Express, homebridge hoffmation and hoffmation-iOS) so I might be helpful for your maintenance and future development, as I'm extending my local unifi portfolio too.

@Shaquu as you commented on my PR, what is your opinion about this?

Best regards

Thiemo

[hjdhjd]

I appreciate the feedback, but I’m not a fan of the tone, which, as you rightly guessed, is harsh at best and condescending at worst.

I believe you’re sincere in your intentions. However, I’d also like you to consider the tone in which I read your comment. I didn’t find it respectful or productive. Here are some thoughts for you:

1. Respect others’ work, contributions, and experiences, especially when they differ from yours. Remember, you don’t have a monopoly on correctness or approach. There are many opinions, and yours are just as valid as anyone else’s.

2. Your original solution creates more problems and maintenance, not fewer. That’s the core issue with your PR. It’s a problematic PR that exacerbates the very things I intentionally solved in a different way. You didn’t respect the author’s intention, and that’s what I find most disappointing.

The issue you raised about exporting a type declared as a development dependency will be addressed in a future release.

I encourage you to be mindful of your tone and how it can be misinterpreted if your intentions aren’t clear. I appreciate that you revised your comment to indicate your intention, but I also hope you take away from this experience that you will get further with a positive, empathetic, collaborative, and curious tone. Take the time to understand your audience if you want to be heard and collaborated with, particularly in the open source world. I’ve been a somewhat prolific open source developer for more than three decades with a lot of code under my belt…it’s not my first project. 😄 That shouldn’t really matter much - you should treat the author with respect and seek to understand their choices if they are different than yours.

Everyone learns something then, and you build bridges.

[theimo1221]

Thanks for the feedback. In my opinion I'm good with programming/logic but rather bad in reporting issues or proposing changes to others and their "baby" without hurting them or sounding like I'm the god of the world/know everything and they couldn't survive without me (which they obviously did all those years before).

Neither do I want to diminish your work nor the time/effort to maintain/explore all those proprietary information/interfaces.

Regarding The issue you raised about exporting a type declared as a development dependency will be addressed in a future release. can I lend you a hand with this?

While my 3rd-Person view might be shortsighted as I'd never be as deep/involved in it as you are I'm still certain the current overlap/entangling of these separate packages might result in plenty of headache in the future.
Just to quote your https://github.com/hjdhjd/homebridge-plugin-utils readme:

homebridge-plugin-utils is a utility library for Homebridge plugins that aims to provide a set of common core capabilities that can accelerate and streamline plugin development

So as stated by yourself it is a utility library for Homebridge plugins and their development and if I understand this package and your intentions with it correctly this should be the independent base of https://github.com/hjdhjd/homebridge-unifi-protect so it's not an homebridge plugin.

Best Regards

Thiemo

[github-actions]

This issue is locked to prevent necroposting on closed issues. Please create a new issue for related support requests, bug reports, or feature suggestions.