feat: ts rewrite and DPT 22, 28 29, 213, 235, 242, 249, 251, 275, 99, 60001 support

[robertsLando]

Improvements/Fixes:

• Error On dpt2 multiple subtypes 001: 010 011 012
• Fix logs on dptlib/index.js (scalar and range not defined)
• Varius dpt typos
• DPT237 apdu_data[1] and [2] assigned to an array instead of a number
• Bumped all deps to latest and fixed all security issues
• Bump min nodejs version to 16
• Remove unused multi-tape dep
• Add linter and prettier for better code style
• Improved tests
• dptlib is now created statically, this makes bundlers happier (no need to follow dinamic require)
• Export of dptlib object. This is useful for applications in order to get informations about datapoints types and subtypes definitions
• Connection.js has been renamed to KnxClient
• Other typos/bugs/optimizations code wise
• Support for DPT: 22, 28 29, 213, 235, 242, 249, 251, 275, 999, 60001.
• Fixed DPT 9,10,18,20,21
• Ensure dpts and other code classes use correct log instance to respect log level passed in options
• Move version print in KnxClient constructor to prevent unwanted logs on console

BREAKING CHANGES

• Minimum required nodejs version is now 16+ (that is already EOL btw)
• Rename Connection to KnxClient and new operator is now manadatory

[robertsLando]

TODOs:

• Fix missing types
• Fix workflow
• Fix package.json
• Rewrite tests using TS
• Add eslint+prettier
• Check logger

[ekarak]

please consider:

• ensuring change to TypeScript won't break our dependents: https://www.npmjs.com/package/knx?activeTab=dependents
• bumping up major version. We're basically porting the library to another language.
• keeping a common text header to all files
• (I'm sure I'm forgetting something)

[ch-zacmo]

Nice to see that someone want to invest time in knx.
I wanted to contribute too since I use it in multiple small and big project. My goal was to add support for knx secure and some features to be able to import the groupAddress for direct DPT mapping, but I didn't have much time recently. Now if the project is going with TS, I will go in my own direction and stay vanilla. I think we need to weigh up whether TS will bring a lot to the table.

[robertsLando]

Now if the project is going with TS, I will go in my own direction and stay vanilla.

Could I ask you why?

[robertsLando]

please consider:

• ensuring change to TypeScript won't break our dependents: npmjs.com/package/knx?activeTab=dependents
• bumping up major version. We're basically porting the library to another language.
• keeping a common text header to all files
• (I'm sure I'm forgetting something)

@ekarak Sure! I will let you know once I end with this but my idea is to keep it full back compatibile!

[ch-zacmo]

Now if the project is going with TS, I will go in my own direction and stay vanilla.

Could I ask you why?

The benefit vs the work necessary to set up, undertand and maintain typescript project will complicate things for me and my colleague. I already don't have much time to do it in the simple way.

[robertsLando]

The benefit vs the work necessary to set up, undertand and maintain typescript project will complicate things for me and my colleague. I already don't have much time to do it in the simple way.

I can understand but trust me I had your same opinion about TS at start and now I feel so bad when I work with an untyped codebase. Also every time I do a TS refactor I found tons of issues and bugs caused by typos that js simply will never spot.

Could you wait a bit I end with this so I can help you working with the TS codebase? It would be much better and easier to debug...

[robertsLando]

@ekarak the PR is almost done (I only need to add eslint and prettier) I kindly ask you if you can take a look at it and also run the wired tests on your end (I don't have a way to run them)

Now to run them simply use: npm run test:wired

[robertsLando]

@ekarak Why no break on this line? Is this expexted? There is also a comment that doens't makes me feel safe adding it

knx/src/FSM.ts

Lines 921 to 922 in ccda6fe

	AddCRI(datagram) // no break!
	// eslint-disable-next-line no-fallthrough

[robertsLando]

Ok I'm done here, please @ekarak make a review when possible :)

The only breaking changes I introduced are:

• Minimum required nodejs version is now 16+ (that is already EOL btw)
• The new Operator is now mandatory when creating a new Knx connection

[ch-zacmo]

Wired test are ok for me. I just did the read storm with 4 as I don't have a bigger actuator.

[robertsLando]

@ch-zacmo Thanks for your feedback! 🙏🏼 Hope @ekarak tests will end well too

[ekarak]

please rebase and test so that we can merge this

[TooAngel]

Just my 5 cent to this PR:

• There is a lot happening for a single PR, it's actually hard to understand what changes why, because of all the different topics addressed. I usually suggest to have a PR per topic.

• Switching to typescript. I'm using typescript a lot in applications, while I prefer javascript in libraries more. The main reason for it: I'm able to review the code and changes easily. With typescript I have a compiler in between, so the generated code is harder to read, high chance that I'm missing something I don't like (intentional or unintentional, just hard to review)

• typescript provides the build-in type generation based on jsdoc. With jsdoc there is a similar level of type checking while developing and it forces to provide some kind of documentation for the library, best of both worlds.

If you want to check it out, I created a commit how this could be done for the connection: TooAngel@a07637a

Some smaller things needs to be done to make the type file really nice, the types.d.ts is autogenerated based on the jsdoc in the Connection.js

[robertsLando]

I have no more time to invest on this, I'm sorry. It took me more then a week to do all this and when I stopped (due to no feedbacks) everything was working flowlessy.

I couldn't agree with any statement against Typescript, nowdays ALL major projects are written in TS and there is a reason if so, you can use JS docs or in line types but that's just a masked Typescript that most people do only because they don't want to learn it (or do such big refactors). I have found many people that were against it then all changed their mind once they started using it

Just by switich to it here I found tons of issues in code and bugs, this is not an opinion but a real fact.

About the code that is different in production: there are source maps that can be used for such purpose, never had any problem with all my projects understanding where the issue is because of TS.

Just to give you an example: I converted to TS also the MQTT.js module (almost 5 milions downloads per month on npm) and before that the project was going to die, now it's back to life as people feel much more confident making changes to code thanks to types

[TooAngel]

Sry, I didn't want to offend someone, just wanted to mention my opinion / give me 5 cent.

In the end it is @ekarak 's decision how to move forward. I just wanted to do a small extension so that I can work better with this library, so I'm fine.

[robertsLando]

@TooAngel Didn't want to be rude anyway with my comment, just wanted to explain my points as well about TS move that I'm pretty sure would be a super nice addition to this project 😄