Export as esm module

[orangecoding]

I cannot import node-hue-api as ESM module. It would be nice if you can support both, ESM as well as Common Modules.

Thanks.

[peter-murray]

What version are you trying this with? The package is supposedly compatible with ESM and CommonJS, I have done some testing on this from the typescript branch, but it is a complete minefield with these settings in package.json and a continuous moving target currently.

If you can provide more context as to where and how you are trying to consume this as ESM then I can validate and test against this in the future updates.

[lesleyxyz]

Same for me, it's saying

Error [ERR_UNSUPPORTED_DIR_IMPORT]: Directory import 'node_modules/node-hue-api/dist/esm/api/discovery' is not supported resolving ES modules imported from node_modules/node-hue-api/dist/esm/index.js
    at new NodeError (node:internal/errors:371:5)
    at finalizeResolution (node:internal/modules/esm/resolve:414:17)
    at moduleResolve (node:internal/modules/esm/resolve:981:10)
    at defaultResolve (node:internal/modules/esm/resolve:1078:11)
    at ESMLoader.resolve (node:internal/modules/esm/loader:530:30)
    at ESMLoader.getModuleJob (node:internal/modules/esm/loader:251:18)
    at ModuleWrap.<anonymous> (node:internal/modules/esm/module_job:79:40)
    at link (node:internal/modules/esm/module_job:78:36) {
  code: 'ERR_UNSUPPORTED_DIR_IMPORT',
  url: 'file:///node-hue-api/dist/esm/api/discovery'
}

when I try to import anything. Node v16.14.0

[everyplace]

I ran into this exact problem, so +1. This branch shows this problem, wherein just by importing the library, I get the above error.

[peter-murray]

Looking into this example you provided, adding --experimental-specifier-resolution=node to the start script allowed the library to load correctly using the esm module variant. The code then has errors as there is no default export, but with some minor tweaks it would run in the example branch you provided.

[Saduff]

--experimental-specifier-resolution=node did not work for me with Node v19.0.0.

What worked was using this custom loader: https://github.com/nodejs/loaders-test/tree/main/commonjs-extension-resolution-loader, e.g. node --loader=./loader.js app.js

However, it seems the issue is because Mandatory file extensions is not followed, i.e. relative imports don't specify file extensions. Adding .js to all relative imports, as well as fully specifying directory indexes fixes the issue as well.

The invalid JavaScript is emitted by TypeScript and there's a discussion about that here: microsoft/TypeScript#42151

Seems like the only viable solution today is to add the .js extension to all relative imports in TypeScript. TypeScript will understand and will then emit valid JavaScript. It's also documented in the TypeScript docs: https://www.typescriptlang.org/docs/handbook/esm-node.html

[tiptronic]

Unfortunately I couldn't get it to work at all as is... (using js exlusively)

It seems we have to go through the complete source and add .js extensions to all relative import statements (as @Saduff already stated).

Did anyone find a solution for this? Or will there be a fix? (I'm using v5 beta 15 on node 19.6.

[peter-murray]

Are you loading the cjs or esm variant? So I can work out how I might resolve this.

[tiptronic]

Oh yes - sorry... I'm trying to use the esm variant using imports and have everything setup as type="module"

The problem seems to only occur, if you run js instead of ts

[peter-murray]

I have done a "quick" pass on this with Node 19 and the refactoring required and using it within another project as a module and it works, but it is no longer backward compatible with Node.js 18.

Also some of the libraries start to generate issues between commonjs and ESmodules...

I think this would require a line in the sand and conversion to Node.js 19 and ESmodule for the whole library to make the work, Not to mention a lot of work to convert the tests into TypeScript as that is also causing issues.

I have parked the changes on this branch for now; https://github.com/peter-murray/node-hue-api/tree/esmodule if you get the time to check if that works under your use cases, it would help me to decide if this is a sensible direction.

I have to work out what the path forward looks like for the updated library as Hue have started to push towards to the new CLIP v2 version now (although it is still missing some functionality, it brings more features).

[tiptronic]

It seems the branch is missing something. All I get when trying to build is this error:

...node-hue-api/src/customTypings/node-dns-sd.d.ts' not found.
  The file is in the program because:
    Part of 'files' list in tsconfig.json

  tsconfig.json:17:5
    17     "src/customTypings/node-dns-sd.d.ts"
           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    File is matched by 'files' list specified here.


Found 1 error.

[peter-murray]

Apologies, the .gitignore file excluded the custom type definition I needed to add, please try again now that I have forcibly added it,

[tiptronic]

@peter-murray this one builds fine and now it works as esm modules!!

Great & thanks!
If I can help you with anything on this project, just drop me a note.
I'm mostly eager to try out the eventstream API to see if that improves the picky bridge's replies