Odd import naming (on version 5 branch)
See original GitHub issueCurrently to get hold of the createLocal
function I am having to do this:
import {v3} from "node-hue-api"
v3.v3.api.createLocal()
Or:
import hueApi from "node-hue-api"
hueApi.v3.v3.api.createLocal()
which is not great!
Much better would just be:
import {createLocal, Api} from "node-hue-api"
createLocal().connect().then((api: Api => {
// do stuff
});
I recommend barrels to export all from each folder so everything is available from the plain import. Removes and deep paths into the package and makes moving things around in a refactor much easier as you don’t break the external interface.
Issue Analytics
- State:
- Created 3 years ago
- Comments:13 (7 by maintainers)
Top Results From Across the Web
Marking of Country of Origin on U.S. Imports
Every article of foreign origin entering the United States must be legibly marked with the English name of the country of origin unless...
Read more >git-config Documentation - Git
NAME. git-config - Get and set repository or global options ... version of the key in which section and variable names are lowercased,...
Read more >May 2022 (version 1.68) - Visual Studio Code
A new setting git.branchRandomName.enable will make VS Code suggest random branch names whenever creating a new branch. The random names are generated from ......
Read more >Tree & Shrub Identification Made Simple
TIP: Opposite-branched trees often lose limbs and branches from diseases or ... Leaf veins export sugars from the leaves down through the tree...
Read more >git - How do I change the author and committer name/email for ...
NOTE: This answer changes SHA1s, so take care when using it on a branch that has already been pushed. If you only want...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
I would say any types exposed on a public function like the ones I show above should be exported to prevent issues like not being able to proxy a function call.
Thanks for the information, appreciate it. I am still trying to wrap up a lot of the exports as I need to be backwards compatible whilst moving this across to TypeScript.
I don’t necessarily want to export everything, as that will constrain me from making implementation changes in the future. This is still a first pass on the TypeScript conversion as I need to remove the
any
and missing definitions and I would expect the majority of these issue to drop out. I will hopefully get a new cut of this out by the end of the week.