search

fable-compiler / fable-node

Bindings for node.js native modules
MIT License
21 stars 5 forks source link

Release stable version for Fable 3.0 #9

Open Zaid-Ajaj opened 5 years ago

Zaid-Ajaj commented 5 years ago

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 commented 5 years ago

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?

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

Done

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

MangelMaxime commented 5 years ago

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

whitetigle commented 5 years ago

Ah great. Thanks!

njlr commented 4 years ago

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

MangelMaxime commented 4 years ago

@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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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.