Skip to content

Export types#181

Merged
RobinBol merged 38 commits into
athombv:masterfrom
JELoohuis:export-types
May 19, 2026
Merged

Export types#181
RobinBol merged 38 commits into
athombv:masterfrom
JELoohuis:export-types

Conversation

@JELoohuis
Copy link
Copy Markdown
Contributor

@JELoohuis JELoohuis commented Apr 10, 2026

Depends on athombv/node-data-types#42

Some of the generated types were incomplete, so I rewrote the generation to document more of the properties available at runtime, as well as adding some additional types based on the JS sources and runtime introspection.

I enabled type checking for the definition file and added the SDK types, since these are used by the ZCLNode.

Some broken enum8 attributes in the Metering cluster definition, where the function was not properly called, were also fixed.

@RobinBol RobinBol self-assigned this Apr 10, 2026
Comment thread .eslintrc.json Outdated
Comment thread package.json Outdated
Comment thread scripts/generate-types.mts Outdated
Comment thread scripts/generate-types.mts Outdated
Comment thread scripts/generate-types.mts Outdated
Comment thread scripts/generate-types.mts Outdated
Comment thread scripts/generate-types.mts Outdated
Comment thread index.d.ts Outdated
Comment thread index.d.ts Outdated
Comment thread index.d.ts Outdated
Comment thread index.d.ts Outdated
@JELoohuis JELoohuis requested a review from RobinBol April 24, 2026 12:54
@JELoohuis JELoohuis marked this pull request as draft April 24, 2026 13:06
@JELoohuis JELoohuis marked this pull request as ready for review April 24, 2026 13:54
JELoohuis and others added 12 commits April 24, 2026 17:49
Several metering cluster attributes were declared with empty enum8
placeholders marked TODO. Comment them out until proper enum values
are defined, and regenerate type definitions.
Align casing with the rest of the codebase: "Zigbee" is the
project's spelling for the protocol name. Updates both the
generated `index.d.ts` and the `scripts/template.d.ts.txt`
source it is rendered from.
Introduce `ZCLNodeInput` describing what the `ZCLNode` constructor
actually reads from its argument: a required `sendFrame` and an
optional `endpointDescriptors` array. The previous typing forced
callers to also provide `handleFrame`, even though the constructor
overwrites that slot, which made directly-constructed `ZCLNode`
inputs unnecessarily painful to type. The full bidirectional
`ZigbeeNode` interface is kept for callers that model the real
Homey-provided node.
Local TypeScript scratch file used to validate the exported types
against a small consumer. Not part of the library output.
`ZCLNode` exposes `handleFrame` at runtime (see `lib/Node.js`),
but the published types omitted it, forcing callers that route
frames manually (e.g. inter-PAN handlers) to cast. Add the
declaration so the public API matches the runtime.
The base `Cluster<Attributes, Commands>` required both generics, so
callers wanting a "cluster of any shape" had to spell out
`Cluster<types.AttributeDefinitions, types.CommandDefinitions>` or
introduce a local alias. Concrete cluster classes (e.g. `BasicCluster`)
already default their generics to their own attribute/command
definitions, so the base class was the odd one out. Default the
generics on the base class to their constraint types, matching the
pattern used by the concrete subclasses and letting callers write a
plain `Cluster` again.
…tatic

These properties are stored on the class (via Cluster.addCluster) at runtime,
not on the instance. The previous declarations as instance properties caused
runtime undefined errors when consumers accessed cluster.attributes etc.
@RobinBol
Copy link
Copy Markdown
Collaborator

@JELoohuis I made some changes that follow from trying to update node-zigbee-clusters in node-zigbee.

The bound command methods present at runtime, such as `move` for a bound LevelControl cluster, could not be added due to TypeScript not allowing for dynamic types on classes. They were only added in a separate interface as to not hinder developers.
@JELoohuis
Copy link
Copy Markdown
Contributor Author

Looks good to me. 👍
The linter and tests are passing for me locally, so if you (or someone else with the proper permissions) could rerun the pipeline they should pass as well.

@RobinBol
Copy link
Copy Markdown
Collaborator

Looks good to me. 👍 The linter and tests are passing for me locally, so if you (or someone else with the proper permissions) could rerun the pipeline they should pass as well.

Could you merge this PR so we can check lint/test in CI? JELoohuis#1

@JELoohuis
Copy link
Copy Markdown
Contributor Author

I installed the @athombv/data-types from the npm registry to fix the remaining pipeline errors. I don't know why the GitHub registry has these access issues, but you may want to change that back once it is fixed, if the GitHub registry is preferred.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

2 participants