Skip to content
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

Add libdeno.builtinModules #1463

Merged
merged 2 commits into from
Jan 6, 2019
Merged

Add libdeno.builtinModules #1463

merged 2 commits into from
Jan 6, 2019

Conversation

ry
Copy link
Member

@ry ry commented Jan 4, 2019

This is needed to support builtin modules like

import { open } from "deno"

This is part of the Native ES modules PR #1460 ... But I think it will be easier to review and land separately.

@ry ry requested a review from piscisaureus January 4, 2019 17:28
@ry ry mentioned this pull request Jan 4, 2019
Copy link
Member

@piscisaureus piscisaureus left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure I quite get the point of this. Are we going to have built-in modules? I thought you were absolutely against namespacing, which suggests that there will be at most 1. Or... what am I missing?

libdeno/binding.cc Outdated Show resolved Hide resolved
libdeno/binding.cc Outdated Show resolved Hide resolved
libdeno/binding.cc Outdated Show resolved Hide resolved
Copy link
Member

@piscisaureus piscisaureus left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you explain a little before you land? I think it might be better to just expose 1 internal module and work the other way, create a module before adding global properties.

ry added 2 commits January 6, 2019 14:41
This is needed to support builtin modules like

    import { open } from "deno"
@ry
Copy link
Member Author

ry commented Jan 6, 2019

Can you explain a little before you land?

With the deno_resolve_cb interface, there's no way to support the built-in "deno" module, because the resolve callback requires you to return the source code of the resolved module. In the case of the "deno" module, we don't even have source that needs to be compiled, but rather just need to export some already-compiled symbols (from the snapshot).

I think it might be better to just expose 1 internal module and work the other way, create a module before adding global properties.

The problem is that at the libdeno abstraction layer, we don't know anything about the "deno" module (defined in js/deno.ts). I don't believe you can create modules and add exports to them after the fact... That said, the way I've done this here is rather hacky and I'd be very willing to change it if we can find a better way.

@ry ry merged commit 1b7938e into denoland:master Jan 6, 2019
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

Successfully merging this pull request may close these issues.

None yet

2 participants