[WIP] Convert to ESM and ES classes

[trusktr]

• [x] Do the similar for roslib. Converted to ESM in the roslib PR.
• [ ] Make GitHub releases contain build artifacts (or open a new issue for it and consider the task here done).

fixes #314

[trusktr]

@MatthijsBurgh Merged develop, updated eslint (no errors on class fields or for-of), tests passing, build updated.

[trusktr]

My longer-term plan is

• convert to TypeScript (which is compilable to WebAssembly with AssemblyScript)
• once I finish GLAS (a port of Three.js to AssemblyScript) and asdom (DOM bindings for AssemblyScript) then I can compile ros3d to Wasm.

[trusktr]

I updated the code to be compatible with native ES Modules (and it now requires a very minimal import-map.json at runtime). To do this, I had to move the needlessly-large EventEmitter2 class into the shims/ folder (I suggesting replacing those 1600 lines of code with the 100 lines of code (half of which is documentation) of the Eventful class from @lume/eventful, but that would be for a breaking release).

The .js file extensions in the import statements are needed for two reasons:

• native ES Module systems (f.e. web browsers) do not automatically append .js extensions to import specifiers. Import specifiers in browsers are simply URLs relative to the current file. Importing path/to/foo will not automatically make a network request for current-file-folder/path/to/foo.js which means trying to download current-file-folder/path/to/foo will fail if that file doesn't exist on the server
• static file servers could be modified to automatically look for a file after adding the .js extension in their implementation, but in practice the average static file server does not do this (they are not js-specific static file servers).

So, by placing .js file extensions in the import specifiers, this makes it easiest to get things working in a native ES Module system without the following workarounds:

• add a build step that appends .js to import specifiers, or
• use a special server that appends .js extensions during it's file lookup.

[trusktr]

Still need to run examples to make sure I didn't break something.

[trusktr]

Added a TODO for roslib. It is not yet classes, and not yet ES Module friendly. I'll do the same thing there.

[trusktr]

roslib got in the way of making this native ES Module friendly. I am going to update roslib to ES Modules first. The good thing is ES Modules are here to stay, officially.

[trusktr]

WIP PR in roslib: https://github.com/RobotWebTools/roslibjs/pull/475

It is possible we can complete this PR without the roslib PR (it just won't have browser-ESM compatible source files, but the built .esm.js bundle will work).

[trusktr]

What are your thoughts on that last commit (ignore build output)?

https://github.com/RobotWebTools/ros3djs/pull/438/commits/f56c58a6f6ba2ef813bb43b5133c05a9e118bc7a

Please let me know if that's ok or if I should keep build output (the reasoning is in the commit message).

[MatthijsBurgh]

What are your thoughts on that last commit (ignore build output)?

f56c58a

Please let me know if that's ok or if I should keep build output (the reasoning is in the commit message).

I think that is OK. I think a repo should never contain compiled files. But these were already there, when I joined. So I kept them.

Might be good that the build files are added as artifacts to releases.

[trusktr]

Might be good that the build files are added as artifacts to releases.

That's true. For that, I think we can automate it.

• Make GitHub releases contain build artifacts (or open a new issue for it and consider the task here done).

[trusktr]

Tests are passing in Node 16. There appears to be some difference between ESM in NOde 14 and 16 that makes tests fail in Node 14.

We can try to fix it, or we can also move forward with Node 16 (this whole change will be a major version bump anyway).

https://github.com/trusktr/ros3djs/runs/3809448165?check_suite_focus=true

[haoming29]

Any updates regarding this PR? Thanks

[MatthijsBurgh]

Stale