Replies: 2 comments 1 reply
-
Additionally - It seems that ALL the imports in the matter-node.js sub-module use the existing npm repo version of the !! Please advise if someone has a workaround for being able to run their own version of "Device.js" to test their clusters against live devices as the node-matter project allowed for this functionality. |
Beta Was this translation helpful? Give feedback.
-
There should be nothing duplicated! So OnOffCluster definition is clearly onkly in matter.js, but yes the "OnOffHandler" is currently still in matter-node.js. This all will change when we move more code from matter-node.js to matter.js step by step in the next time. We have a fukl move concept at #62 which is in discussion. That means, as of today, the Cluster definitions should all go into matter.js package. All rest regarding "implementation" matter-node.js is the better place now. We will make sure t move that over time into the correct place. It is correct that it is currently not that easy to develop "the library" AND also another package to use it. Here a temporary idea could be to create an own further package in the packages directory which would then, when using "npm i" on the matter.js root level should be bound correctly ... Yes you need to make sure to not commit that new package but for development time this should be most easy for now. I understand that this is not that easy for now and that we need to work on optimizing this ... and yes always lets chat in Discord if you have question! |
Beta Was this translation helpful? Give feedback.
-
Working with the newly merged libraries, I am running into issues with the sub-module directory structure. There doesn't seem to be a clear delineation of responsibilities in the submodules with cluster definitions in one place and the server for the cluster in the other sub-module.
Additionally, things like OnOffCluster exist in both submodules.
What is the goal or intention of keeping matter-node.js and matter.js separate and what logic should exist in each if there is a good reason to keep them seperate?
Would it be easier to get the library back functional for those trying to leverage it and contribute to the clusters to merge the two sub-modules for the time being and then if the library gets unwieldy larger in the future, split it out then?
It seems it would be easier to get contributors on the project if the structure were less complex and the library were useable via 'npm i ' until the project is more mature and ready to be built for the public npm repo.
Maybe a Discord channel discussion is in order?
my 2 cents.
Wes
Beta Was this translation helpful? Give feedback.
All reactions