Rxjs: Support rxjs for deno

[mtwzim]

Feature Request

Hello guys, recently I am working on a version of rxjs for deno. Well the version I modified is already working, but when talking to Ben, he guided me to create an issue so we can fix this,

Describe the solution you'd like
When talking to ben, we can have a code for the node and the node, is that possible? My version of rxjs for deno is here: https://github.com/DenoBRComunitty/rxjs

What can we do about it?

Sorry for my bad issue.
Bye

[benlesh]

Well, I think first we need to understand what all does not work in Deno. Do you happen to have a comprehensive list of what isn't compatible?

[mtwzim]

In fact, it is very easy to migrate to deno (in the case of RxJS, you can see by the small amount of commits that I had to make in my repository). Well nothing at NodeJS api https://nodejs.org/api/ works on Deno, this includes the file system ("fs"). https://doc.deno.land/https/github.com/denoland/deno/releases/latest/download/lib.deno.d.ts this is an API that should be used.
Changing the RxJS itself is very easy, in 30 minutes this is done, the real problem is the tests on node and builds, this is not yet available on Deno and has to be done on the node, although it is possible to use tools like CircleCI and TravisCI to do the tests, it works and I already tried.
In addition, deno uses another means of import, the import / export of files must have the extension explicit, example:
export { Observable } from './internal/Observable';
in Deno is:
export { Observable } from './internal/Observable.ts';
I think that's just it.

[kwonoj]

As described above, biggest blocker is import path interop between two different runtime : esp to support node.js esm (which also requires proper extension) maintain compatibility / non breaking change it is something we need carefully evalute. This is primary reason I'm going to focus esm support first withou breaking existing published pkg (this is whole another tricky story) then consider new runtime's path support.

[mtwzim]

@kwonoj I talked with ben, I believe that it is not possible to maintain as 2 versions in a single project, it is not impossible, but it requires a lot of effort, it is easier to make a fork, adapt to the deno and configure the .git to receive 2 origins, the fork and the original rxjs, so you can get 2 versions (rxjs original and rxjs deno) without getting conflicts. That's what I did, you can also analyze this possibility, I believe that you are not limited to just 1 repository per language, the javascript despite being a single language, have several runtimes, now have the deno, maybe you could consider that: there is no way to offer support to all existing runtimes in just one code?

[mtwzim]

While RxJS is not available for Deno by the ReactiveX team, I and the community in Brazil which I am one of the creators, we will continue to provide a version for Deno, for documentation is available at: https://rxjs.denobr.com/
The source code is available in:
https://deno.land/x/rxjs and https://github.com/DenoBRComunitty/rxjs

[garronej]

@mtwzim @kwonoj @cartant It is definitively possible to bring Deno support without having to maintain a port or introducing breaking changes!
I pulled it off with EVT.
The build tool that made it possible is Denoify.
I thought you guys might want to check it out.

I would be happy to help if you need me.

Regards

[mtwzim]

Thanks for your comment! But... why does everyone insist on using third party tools? Denoify? DenoModules? I created RxJS for Deno to add more support to Deno Comunitty, but I would like this support to be from ReactiveX itself, as I said in the last comment, the easiest solution to be done, which prevents adding support to Deno? that already was done with so many things, including the Node.

[garronej]

@mtwzim, My message was mainly addressed to @benlesh @kwonoj and @cartant, Denoify is for NPM module maintainer that wants to bring support to Deno without having to maintain a dedicated port. Your approach requires to manually keep in sync two nearly identical versions of the same codebase. On the other hand, setting up Denoify is a one-time cost.

PS: I am appreciative of the time and effort you spent on RxJS for Deno, I just think it is not the best approach here.

[mtwzim]

You're right, my approach to rxjs is not the best. But, Denoify would also require a dedicated port, a synchronization (maybe not manual, can be done with GitHub's api's), but one thing you are sure I didn't notice in the last comment, Denoify can help to compile and make this faster process.
Or am I wrong?

[garronej]

Actually no, there is no need for a distinct repo.
Have a look at EVT, there is one single repo that is both the home of the NPM and the Deno third-party module.
There is only something to be decided about the naming convention of the Deno's GitHub releases but that is all.

[garronej]

@benlesh @kwonoj @cartant Hi,
As a proof of concept, I have set up Denoify on a fork of RxJS.
It almost works out of the box, there was just a couple of @ts-ignore to drop here and there.

The diff.

Now there is just some CI scripting to do for publishing cleanly on deno.land/x without tracking any dist file on the main branch.

I'll be happy to do it but I would need to have a word with you first, there are some points that need to be discussed.

Let me know if you are interested :octocat:

[benlesh]

Definitely interested. I'm curious about why we needed the ts-ignore, and I'd like to understand more about what this is doing.

[mtwzim]

Definitely interested. I'm curious about why we needed the ts-ignore, and I'd like to understand more about what this is doing

Sorry to intrude, but, I believe it is due to the return of the requestAnimationFrame functions, if I'm not mistaken they return any type. and as for example, id is a number type and then id = requestAminationFrame (run) returns any type, the typescript should throw the error.

[garronej]

@benlesh Cool!
Regarding the @ts-ignore: requestAnimationFrame() and cancelAnimationFrame() are DOM API methods that Deno and Node do not implement. Those methods are defined inlib.dom.d.ts, definition file that Deno does not use by default.
You cleverly avoided relying on lib.dom.d.ts definitions everywhere else so I assume this was just a slip-up.

What Denoify does is, every time you hit npm run compile, it produces a Deno distribution of RxJS from the src directory that it places in /dist/deno alongside the other targets.
Considering that RxJS has no dependency the only things that needs to be fixed are the import/export statements.

Becomes

Now what's left to do is the workflow to publish on the Deno third-party module repository.

Would you like me to explain how I would implement it? As I say I'll be happy to set everything up for you.

[andykais]

is there a reason this issue was closed @mtwzim?

[mtwzim]

@andykais No, none, if you want we can open it again. But ... the last post was on June 22, I thought they had given up on it.

[andykais]

I think if there is still interest in a port (I certainly am interested) then leaving an issue open is a good way to funnel interest into one place (devs who are interested can either help with porting the library, or just show their interest by giving a 👍 on the issue). If the rxjs contributors feel the need to do housekeeping and close out dead issues, then thats up to them. Generally though, its fine to leave an issue open if the issue is not solved