Release stable version for Fable 3.0

[Zaid-Ajaj]

We have been keeping track of the progress to publish all libraries to Fable.Core 3.0 stable. Looks like package is still on the beta version. Can you please release a stable version too? if not, what is needed and how can I help?

Cheers

[whitetigle]

Well, I haven't finished checking all the bindings. Also I haven't finished adding tests to check that the bindings are actually working.

So that's a lot of work and I can't finish it right now since It implies checking everything against the actual node API in order to get sure we're on par and up to date.

What's remaining?

• ChildProcess.fs
• Crypto.fs
• Events.fs
• Fs.fs
• Http.fs
• Https.fs
• Net.fs
• Performance.fs
• Process.fs
• Querystring.fs
• Stream.fs
• Tls.fs

What does it mean? I guess the current version could be published and work against Node.js 6.x But there are many things that could get deprecated soon in order to support LTS (currently Node.js 10.x)

So my question is: do we have a real time constraint here? If so what is it?

Thanks!

[nojaf]

Actually I'm not 100% sure that list is complete, I'm missing Cluster for example.
I personally don't have a time constraint for this, the prerelease version works fine in my project with Fable.Core 3.

[whitetigle]

Actually I'm not 100% sure that list is complete, I'm missing Cluster for example.

You're right, I haven't checked the whole API. But at least that's the things we have yet to update from the former fable-import project.

I personally don't have a time constraint for this, the prerelease version works fine in my project with Fable.Core 3.

Ah maybe we should publish a new version since I merged my recent updates on Buffer. 😉

[whitetigle]

Actually here's the actual progresses made on the updates:

Done

• Buffer (from 1.0.0-beta-0.0.1)
• OS (from 1.0.0-beta-0.0.1)
• Path (from 1.0.0-beta-0.0.1)
• Url (from 1.0.0-beta-0.0.1)
• Performance Hooks (from v1.0.0)

Remaining

No check does not mean it doesn't exist or can't be used. It rather means that, in case the bindings already exist, we need to improve them

• Child Processes
• Cluster
• Crypto
• DNS
• Domain
• Errors
• Events
• File System
• HTTP
• HTTP/2
• HTTPS
• Inspector
• Internationalization
• Net
• Process
• Query Strings
• Readline
• REPL
• Report
• Stream
• String Decoder
• Timers
• TLS/SSL
• Trace Events
• TTY
• UDP/Datagram
• URL
• Utilities
• V8
• VM
• Worker Threads
• Zlib

[MangelMaxime]

@whitetigle I changed it into a checklist so it's possible to just check the items when done

[whitetigle]

Ah great. Thanks!

[njlr]

Is it possible to use the TypeScript bindings + the automatic conversion tool?

[MangelMaxime]

@njlr Yes it should be doable (it is what we did in the past), but I think we end up making the binding by hand because they are better crafted and have a more friendly API.

[AngelMunoz]

Node 10.x is EOL April 2021
should new/updated bindings target node v12 now or for the moment keep targeting 10? I'm asking for a friend 😁

[alfonsogarciacaro]

If I'm not mistaken, the bindings don't target any specific Node version. But it's true that depending on the Node version you're using some of the bindings here may have been deprecated or some new APIs may still be missing.

In any case, I think there's no maintainer currently for the Node bindings. It'd be great if somebody using them could step in and make the updates when needed 🙏

[whitetigle]

I cam jump back in the boat if that's ok for you.
One question though: I was thinking about making a branch for each Node.js release (10.x, 12.x, etc..). What do you think?

[njlr]

Actually here's the actual progresses made on the updates:

Done

* [x]  Buffer _(from 1.0.0-beta-0.0.1)_
* [x]  OS _(from 1.0.0-beta-0.0.1)_
* [x]  Path _(from 1.0.0-beta-0.0.1)_
* [x]  Url _(from 1.0.0-beta-0.0.1)_
* [x]  Performance Hooks _(from v1.0.0)_

Remaining

No check does not mean it doesn't exist or can't be used. It rather means that, in case the bindings already exist, we need to improve them

* [ ]  Child Processes
* [x]  Cluster
* [ ]  Crypto
* [ ]  DNS
* [ ]  Domain
* [ ]  Errors
* [ ]  Events
* [ ]  File System
* [ ]  HTTP
* [ ]  HTTP/2
* [ ]  HTTPS
* [ ]  Inspector
* [ ]  Internationalization
* [ ]  Net
* [ ]  Process
* [ ]  Query Strings
* [ ]  Readline
* [ ]  REPL
* [ ]  Report
* [ ]  Stream
* [ ]  String Decoder
* [ ]  Timers
* [ ]  TLS/SSL
* [x]  Trace Events
* [ ]  TTY
* [ ]  UDP/Datagram
* [ ]  URL
* [ ]  Utilities
* [ ]  V8
* [ ]  VM
* [ ]  Worker Threads
* [ ]  Zlib

This check-list seems outdated (for example File System is mostly covered).

Which bindings are remaining?

Perhaps each one should have its own issue.

[alfonsogarciacaro]

I cam jump back in the boat if that's ok for you.

Of course that's ok with me @whitetigle 😄

One question though: I was thinking about making a branch for each Node.js release (10.x, 12.x, etc..). What do you think?

Whatever makes it easier to maintain should work I guess. If you're planning to map Fable.Node versions with Node LTS releases (e.g. Fable.Node 1.x <-> Node 10.x, Fable.Node 2.x <-> Node 12.x) a branch for each makes sense.

[Choc13]

Just wondering what the status of this is now? I'm trying to use Node.Crypto for example and it seems like the types are there in the IExports object (well at least for the bit that I need this is randomBytes), but it's just missing the final import at the bottom such as

[<Import("*", "crypto")>]
let Crypto : IExports = jsNative

Or I am just misunderstanding how this is supposed to be consumed? If there's just a few bits like this missing I'm happy to help out with adding them too as I'm going to need to add these to my project anyway.

[Choc13]

Ah, I've just found that all of those IExports are defined in Api.fs, so I just need to open Node.Api and then I can use crypto.randomBytes from there. Sorry about that.