WIP: Make examples ESM and add ESM to node-ble

[vilicvane]

• Changed package.json type for both matter-node-ble.js and matter-node.js-examples to "module".
• Added missing .js file extension for matter-node-ble.js.
• Added require that works in both CJS and ESM using Node.js package.json. Other better ways?

[Apollon77]

I need to check the exports on a big screen (just mobile right now) but yes that require thingy seems to be that way as only available option. Will check latest tomorrow.

[vilicvane]

Don't know, it actually surprised me that there's little discussion related to this.

I am thinking about importing the dual format require with relative path as well, what do you think?

[Apollon77]

@vilicfor the "require": We could also simply make the "loading"methdod async and use await import?

[vilicvane]

@Apollon77 Yes but that would introduce noticeable changes. Currently both bleno and noble usages are synchronized, as top level await is only supported in esm (actually relatively recent esm).

[Apollon77]

wait ... look deeper ... bleno and noble requires ia both "lazy" in a method, e,.g. https://github.com/project-chip/matter.js/blob/main/packages/matter-node-ble.js/src/ble/BlenoBleServer.ts#L31 so it is not top level :-)

so when we make this "Initialize" method async then all should be fine.

PS: Yes because initialize is done in constrzuctore we would needs to adjust that a bit, but like the "create" methods we use elsewhere for the same reasons

[vilicvane]

Yes, I mentioned top-level await because if that could be done, there's nothing need to change elsewhere.

And asynchronousness is contagious, I took some reference looking up, and there might be a tree to update. I'll do whatever you want. ;)

[lauckhart]

Yes, I mentioned top-level await because if that could be done, there's nothing need to change elsewhere.

I think given the migration to ESM top-level await is fine, desirable even in this case.

[Apollon77]

SO tehe question is still if we should use this "extra exposed require" or if we just switch the "Inititialize" methdos to async and use an await import there ... then we do dnot need this requiets special stuff

[lauckhart]

Switching to async initialization would be ideal but I'd leave up to @vilic since he's doing the work. :) Could also accept with the require and add a TODO for swapping to async.

@vilic FWIW we've dealt with "cascading async refactors" before and they aren't usually too terrible since a lot of our initialization code is already async.

[vilicvane]

@lauckhart I'll leave the PR as-is then. 😄

I just tried the "cascading async refactor" (nearly finished) but as it changes some API (e.g. Ble) and I don't feel good changing the API for compatibility with legacy versions of runtimes.

Also, there are some issues with Bleno initialization refactor that might require putting things in different places which I think would require aligning with your preferences.

I think it's better to be done by you guys so you can make sure there's no unnecessary compromises.

[JimBuzbee]

I know it's a bit late :-) But "npm run bundle-device" in the examples directory no longer works:

[ERROR] Could not resolve "dist/cjs/examples/DeviceNode.js"

Is that a result of this change?

[vilicvane]

@JimBuzbee Seems to be caused by this PR. You may temporarily fix this by replacing all cjs in packages\matter-node.js-examples\package.json with esm. Will submit another PR to fix.

Turned out to be a little bit more complicated than I thought. esbuild does not support either polyfilling import.meta.url for cjs nor polyfilling require() for esm... Still trying to find a way.

[vilicvane]

@JimBuzbee I have submitted a PR fixing this, please check it out.

[Apollon77]

Fix released as new Nightly

[JimBuzbee]

@vilicvane - Thanks for the quick response - works for me now.

[Apollon77]

Next nightly is also on it's way, sorry