Skip to content

feature-request: Expose the same API in node.js #2184

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
WillAvudim opened this issue Apr 23, 2019 · 16 comments
Closed

feature-request: Expose the same API in node.js #2184

WillAvudim opened this issue Apr 23, 2019 · 16 comments

Comments

@WillAvudim
Copy link

Would it be possible to get access to exactly the same API in Node.js?

I found the API surface overall to be exquisitely neatly designed, and I like it a lot. I'd like to be able to seamlessly switch between Deno and Node.js without memorizing strikingly different OS/file APIs.

@GrosSacASac
Copy link

That is a non goal

from https://deno.land/manual.html#introduction

Non-goals

Not explicitly compatible with Node.

@zekth
Copy link
Contributor

zekth commented Apr 23, 2019

Some polyfills are available as third-party modules but it will not be implementend in deno.

@ry
Copy link
Member

ry commented Apr 23, 2019

As @zekth suggests, we could have an API in deno_std that acts as a polyfill. Something like this:

import { readFileSync } from "https://deno.land/std/node/fs"

@zekth
Copy link
Contributor

zekth commented Apr 23, 2019

Having it in deno_std is not good for me. I'd better create an official polyfill repo, like deno_polyfills

@WillAvudim
Copy link
Author

WillAvudim commented Apr 23, 2019

Thank you for not killing this proposal outright on the spot :-)

Node.js API surface is enormous with lots of legacy pre-async-await artifacts. Bringing it into Deno is indeed undesirable. If we could bring Deno API to Node.js, one way or another, it would make way to write libraries that support both Deno and Node.js.

@zekth
Copy link
Contributor

zekth commented Apr 23, 2019

The only thing we need to focus on is the CI checking. We have to make test between deno and node to have the same output. Also this may need a generic test runner. That's my concern about adding it to deno_std. Add special steps just for polyfills may slow down the ci.

Or maybe we can gather development with this issue: denoland/std#333

@kevinkassimo
Copy link
Contributor

I agree that we might want to dedicate another repo instead of deno_std for the node-compat modules, since we are likely to need two different kind of issue trackers

@ry
Copy link
Member

ry commented Apr 24, 2019

@kevinkassimo I'm not opposed to doing it in a separate repo - but why do they need to different kind of issue trackers?

@kevinkassimo
Copy link
Contributor

kevinkassimo commented Apr 24, 2019

@ry Since I believe most of the issues will be about incompatibilities/different output with Node API instead of proposing new functionalities

@ry
Copy link
Member

ry commented Apr 25, 2019

@kevinkassimo Ok sure. Does anyone want to start a repo outside of denoland for this? We can point people to it in the manual as the semi-official binding layer. I feel like things might move faster if I'm not in the loop. If it works out and is useful we can consider moving it into deno_std later.

@zekth
Copy link
Contributor

zekth commented Apr 25, 2019

@kevinkassimo
Copy link
Contributor

@zekth Yeah I think this works

@kevinkassimo
Copy link
Contributor

@zekth @ry Inited project in https://github.com/denolib/node

@MarkTiedemann
Copy link
Contributor

There's also https://www.npmjs.com/package/deno which tries to bring the Deno API to Node (see: denoland/deno_install#6).

@realJoshByrnes
Copy link
Contributor

Following... I might be able to assist with this.

@bartlomieju
Copy link
Member

Closing in favor of #2644

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants