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

fix typescript warning #99

Merged
merged 2 commits into from
Jun 4, 2018
Merged

fix typescript warning #99

merged 2 commits into from
Jun 4, 2018

Conversation

ztplz
Copy link
Contributor

@ztplz ztplz commented Jun 2, 2018

[ts] Return type of exported function has or is using private name 'AmdDefine'.

@CLAassistant
Copy link

CLAassistant commented Jun 2, 2018

CLA assistant check
All committers have signed the CLA.

Copy link
Contributor

@qti3e qti3e left a comment

Choose a reason for hiding this comment

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

Nice! thank you...

@ry ry merged commit 37dd416 into denoland:master Jun 4, 2018
@ry
Copy link
Member

ry commented Jun 4, 2018

Thanks.

@trusktr
Copy link

trusktr commented Dec 21, 2019

The exports should not be required to make things work, because it changes the exposed API which may be something undesirable in some cases.

I've opened a request to fix issues like these in TypeScript by bringing declaration files to parity with language features. microsoft/TypeScript#35822

hardfist pushed a commit to hardfist/deno that referenced this pull request Aug 7, 2024
…oland#99)

The way `JsRuntime::init_extension_js` initialized ESM extensions
without a snapshot was by running the event loop and blocking the
thread ntil there were no more tasks. This works fine for the main
realm, because it is created before any user code can start any async
ops. However, other realms may be created while async ops are running,
which would make realm creation hang until those ops are resolved.

Since extensions are not expected to use top-level await, there would
be no need to run the entire event loop for modules to resolve;
calling `JsRealm::evaluate_pending_module` would be enough. If the
module is not resolved after calling that functions, then it or one of
its dependencies has TLA, in which case we panic.

Since a panic like "TLA is not allowed" would be hard to debug,
especially on codebases with many modules, we use
`ModuleMap::find_stalled_top_level_await` to find at least one of the
TLA locations, and we display it in the panic message.
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.

5 participants