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

Handling dependencies not specified in the IDL #81

Open
danyao opened this issue Oct 6, 2017 · 5 comments
Open

Handling dependencies not specified in the IDL #81

danyao opened this issue Oct 6, 2017 · 5 comments

Comments

@danyao
Copy link
Contributor

danyao commented Oct 6, 2017

I'm using webidl2js to generate JavaScript interfaces for web API polyfills. My IDL may depend on other interfaces that are already natively supported in a browser. webidl2js seems to expect to be part of a complete system generating all dependent interfaces from scratch. So it generate require statements for these dependent interfaces as well.

Manually removing the require statements from the generate JS is not a full solution because there are accesses to <DependentType>.interface.prototype and built-in types don't have the interface field.

Perhaps webidl2js could assume any interfaces not specified in the IDL directory are provided already?

@TimothyGu
Copy link
Member

With suppressErrors option and unknown types (types whose IDL definition is not available), no require statements are generated. For better support for interfaces not implemented through webidl2js, see #69.

@domenic
Copy link
Member

domenic commented Oct 7, 2017

@TimothyGu what happens to the output? Do we have tests? Do they use e.g. global.EventTarget or do they try to use global.EventTarget.interface? I'm not sure we should close this so hastily, although indeed suppressErrors might be the right answer.

@TimothyGu
Copy link
Member

what happens to the output?

In @danyao's case I assume they add all the IDL fragments into webidl2js even for the interfaces not implemented with webidl2js. If only the IDL interfaces that are to be implemented with webidl2js are added to the transformer (as is the case for jsdom), we currently try to convert it by checking if the given object has our impl symbol, and if so unwrap the value using that symbol.

Do we have tests?

No, because our tests don't have suppressErrors enabled at the moment.

@TimothyGu TimothyGu reopened this Oct 7, 2017
@danyao
Copy link
Contributor Author

danyao commented Oct 11, 2017

Our IDLs looked like this:

interface PaymentRequestUpdateEvent : Event {
    void updateWith(Promise<PaymentDetailsUpdate> detailsPromise);
};

PaymentRequestUdateEvent is to be implemented by webidl2js, but Event is already supported in the user agent natively. webidl2js generated JavaScript that looks like this:

const Event = require("./Event.js");
...
Object.setPrototypeOf(PaymentRequestUpdateEvent.prototype, Event.interface.prototype);

This results in two errors:

  • require can't find "./Event.js"
  • Event.interface.prototype fails because Event doesn't have an interface attribute.

@domenic
Copy link
Member

domenic commented Apr 17, 2020

Solving this would be helpful for the Streams Standard reference implementation, which runs its own webidl2js-generated code inside a jsdom environment, and would like to use that jsdom environment's AbortSignal. Currently the AbortSignal is not type-checked at all.

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

3 participants