A promise-based library for securely communicating with iframes via postMessage.
Fixes #85 which is an issue where an error would occur under specific timing scenarios when the child iframe is removed from the DOM at about the same time it sends a SYN message. The error didn't cause operational issues, but would still be an uncaught error.
Added some documentation to the readme regarding TypeScript usage.
Added support for a wildcard as a value for childOrigin. This allows the parent to communicate within any child origin.
Thanks @KutnerUri for the contribution!
The methods object passed to connectToParent or connectToChild can now contain nested objects with function values. See https://github.com/Aaronius/penpal/pull/71 for more information.
With a major release comes breaking changes. Here's what you need to know:
The NotInIframe error, which was thrown if connectToParent was called from outside of an iframe, has been removed. Fixes #61.
Previously, if a call was made to connectToParent from outside of an iframe, Penpal would throw an error with the NotInIframe error code. While this was a nice idea, it didn't play well with Cypress. Cypress by default attempts to "modify obstructive code". In other words, if any JavaScript attempts to perform framebusting, Cypress tries to modify the code since such techniques prevent Cypress from working properly. As it turns out, Penpal's check to see if it was running inside of an iframe was not performing framebusting, but Cypress would see it as obstructive code anyway and attempt to modify it, which would actually break testing with Cypress + Penpal entirely. The workaround wasn't great and, given that Penpal's check wasn't providing a lot of value, I decided it would be in consumers' interest to remove the check.
Previously, Penpal would reject the connection promise with an error containing the ConnectionDestroyed error code if the consumer called connection.destroy before a connection was made. Fixes #51.
When a consumer calls destroy, they are intentionally destroying the connection and shouldn't be forced to handle a rejected promise as a consequence. It's not an exceptional use case, so it does not merit a rejection. This change should lower development burden, as described in #51.
The ConnectionDestroyed error is still thrown if a child or parent method is called after a connection has been destroyed.
This is not a breaking change. The following TypeScript types are now exported as named exports: Connection, AsyncMethodReturns, CallSender, Methods, and PenpalError types. Fixes #67.
TypeScript types could previously (and still can) be imported through a child path as follows:
import { Connection } from 'penpal/lib/types';
but that made them less discoverable and the fact that they could be relied on was only implicit. They are now named exports on the top-level module, so they can now be imported as follows:
import { Connection } from 'penpal';
connection TypeScript type.Big thanks to @lpellegr for his work on these issues!
Rather than creating copies of the typescript declarations for es5, I switched to leveraging the types field in package.json to point to the typings that were generated when the typescript files were compiled to es6. Besides reducing the need for duplicate declarations, it's also advised by the TypeScript documentation.
Now publishing TypeScript typings alongside ES5-generated code.
Removed add-module-exports babel plugin since it's unnecessary. This shouldn't have any effect on consumers.
Prior to v5.0.0, I had transpiled Penpal code to es5 before packaging for npm. Starting with v5.0.0, I decided to only bundle for es6 with the hope that bundler support for es6 would be strong enough that packaging es5 would be unnecessary and consumers could configure their bundler to transpile penpal back to es5 if necessary. Due to popular demand and because bundlers can be a pain to configure to transpile penpal to es5, I added back transpilation to es5.
The npm package now includes both es6 and es5 code. If the consumer's bundler is capable of bundling es6 code, it should use the es6 code automatically. If it's not capable of bundling es6 code, then Penpal's es5 code will be used automatically instead.
This should not affect the runtime behavior of Penpal in any way.