Export frequently used things from the main entry point #762
Conversation
|
Most of the data coming out of the CCs I need access to are enums and types related to the CC. For example, CentralSceneKeys from CentralScene, or ColorTable from my Color Switch MR |
|
Man, I love TypeScript. You can now just add a JSDoc comment containing |
|
Ok, I think I like it now. Additionally to the main entry point, there are now the following entry points:
All their contents are also exported by the main entry point if you prefer that. Once this is merged, you can consider the internal structure ("build/...") deprecated. After 3.0.0, I will likely make changes to it. |
|
I checked out and built this branch, but it does not seem to be generating any top level |
| @@ -131,13 +137,6 @@ function getTargetColorValueID( | |||
| }; | |||
| } | |||
|
|
|||
| export interface ColorSwitchGetResult { | |||
There was a problem hiding this comment.
This was intended to be the return type of ColorSwitchCCAPI.get, looks like I forgot to specify it in my earlier MR
There was a problem hiding this comment.
I've resorted to turning off the explicit return type check for the more complicated API methods.
There was a problem hiding this comment.
Its still useful to have, so that typescript users can know what to expect from the return type. At least keep the interface and let typescript users cast it on their own.
There was a problem hiding this comment.
The information is still there in the generated .d.ts files - its just not explicitly specified in the source file.
|
The top level entry points are only generated for the npm package and cleaned up afterwards to keep the directory and git clean. If you want to work with a locally linked copy, just run |
With this PR we now export the most frequently used things from the main entry point.
@RoboPhred please take a look if you're missing something. The CCs and their enums etc. are not exported yet, I'll need to automate this.
My plan is to have a clear structure of the exports that loosely matches the lib directory. If you have some input on this, I'd like to know:
zwave-js: Like before, only the most basic stuff (Driver, Node, maybe Controller)zwave-js/CommandClass: Everything related to CCs (including the CommandClasses enum)zwave-js/Values: ValueID, Metadata, ...And since my use case for the library is pretty unspecific, I could use some help understanding how others use this library. What do you need exported from the CC files? My intention with the node API (node.commandClasses.xyz.abc()) was that you don't need to have access to the CC classes directly.
fixes: #761