chore(deps): bump jsdom and expo-module-scripts

[dependabot[bot]]

Bumps jsdom to 20.0.3 and updates ancestor dependency expo-module-scripts. These dependencies need to be updated together.

Updates jsdom from 11.12.0 to 20.0.3

Release notes

Sourced from jsdom's releases.

Version 20.0.3

• Updated dependencies, notably w3c-xmlserializer, which fixes using DOMParser on XML documents containing emoji.

Version 20.0.2

• Fixed xhr.abort() to no longer give an exception when the constructed XMLHttpRequest was invalid. (whamtet)
• Fixed event.getModifierState() on MouseEvent and KeyboardEvent instances to properly consult the ctrlKey, altKey, metaKey, and shiftKey properties of the event. (juzerzarif)
• Fixed custom element creation to not be affected by any modifications to the window.customElements property. (bicknellr)

Version 20.0.1

• Improved the performance of appending <option> elements to <select> elements. (TheHound)
• Fixed location.pathname getter to not crash when the JSDOM instance was created using an opaque-path URL, including the default URL of about:blank.
• Fixed crypto.getRandomValues() to accept typed array subclasses. (sebamarynissen)
• Updated various dependency minor versions. Notably, nwsapi fixed some selectors bugs, and tough-cookie fixed some cookie bugs.

Version 20.0.0

• Node.js v14 is now the minimum supported version.
• Added crypto.getRandomValues(). (sjrd)
• Added HTMLFormControlsCollection and RadioNodeList, so formEl.elements now behaves correctly. (UndefinedBehavior)
• Added the signal option to addEventListener(). (cheap-glitch)
• Fixed the :root pseudoclass to work correctly. (hughs-ch)
• Updated parse5, bringing along some HTML parsing and serialization fixes. (fb55)

Version 19.0.0

• Changed jsdom.nodeLocation() to return undefined when used on nodes that originate via fragment parsing (e.g., via innerHTML). Previously it would return based on the node location of the fragment string, which made node locations unreliable with respect to the original document source. This restores the behavior that was present in v14.0.0, and was accidentally broken in v14.1.0. (bakkot)
• Fixed calling window.close() inside the Window's load event to no longer crash. (MattiasBuelens)

Version 18.1.1

• Fixed connectedCallback to fire in situations involving document fragments, which was broken in v18.0.1. (GrantGryczan)

Version 18.1.0

• Fixed headers.append() and headers.set() to normalize values. (MattiasBuelens)
• Fixed pageshow events to have bubbles: true and cancelable: true. (MattiasBuelens)
• Implemented the reason property on AbortSignals, along with the corresponding reason argument to abortSignal.abort() and AbortSignal.abort(). (MattiasBuelens)

Version 18.0.1

• Fixed live Ranges to update correctly after calling node.normalize(). (hgiesel)
• Fixed live Ranges to update correctly after removing child nodes. (hgiesel)
• Fixed setting inputEl.valueAsDate = null to no longer throw an exception, but instead set the value to the empty string. (simon-weimann)
• Improved performance of node insertion and node.contains(). (GrantGryczan)

Version 18.0.0

Potentially-breaking bug fixes:

• Fixed SSL certificate checking for WebSocket connections. Previously, invalid SSL certificates were always accepted; now, they properly respect the ResourceLoader's strictSSL option (which defaults to true).
• Changed the global in which almost all Promise and TypeError instances are created to be the jsdom global, not the Node.js global. This could affect any code that uses instanceof.

Other changes:

• Fixed moving an element between HTML and XML documents to reset the tagName cache, allowing it to return a lowercase value once it's in the XML document. (LucasLefevre)
• Fixed form submission to not happen when the form is invalid. (pozil)

... (truncated)

Changelog

Sourced from jsdom's changelog.

20.0.3

• Updated dependencies, notably w3c-xmlserializer, which fixes using DOMParser on XML documents containing emoji.

20.0.2

• Fixed xhr.abort() to no longer give an exception when the constructed XMLHttpRequest was invalid. (whamtet)
• Fixed event.getModifierState() on MouseEvent and KeyboardEvent instances to properly consult the ctrlKey, altKey, metaKey, and shiftKey properties of the event. (juzerzarif)
• Fixed custom element creation to not be affected by any modifications to the window.customElements property. (bicknellr)

20.0.1

• Improved the performance of appending <option> elements to <select> elements. (TheHound)
• Fixed location.pathname getter to not crash when the JSDOM instance was created using an opaque-path URL, including the default URL of about:blank.
• Fixed crypto.getRandomValues() to accept typed array subclasses. (sebamarynissen)
• Updated various dependency minor versions. Notably, nwsapi fixed some selectors bugs, and tough-cookie fixed some cookie bugs.

20.0.0

• Node.js v14 is now the minimum supported version.
• Added crypto.getRandomValues(). (sjrd)
• Added HTMLFormControlsCollection and RadioNodeList, so formEl.elements now behaves correctly. (UndefinedBehavior)
• Added the signal option to addEventListener(). (cheap-glitch)
• Fixed the :root pseudoclass to work correctly. (hughs-ch)
• Updated parse5, bringing along some HTML parsing and serialization fixes. (fb55)

19.0.0

• Changed jsdom.nodeLocation() to return undefined when used on nodes that originate via fragment parsing (e.g., via innerHTML). Previously it would return based on the node location of the fragment string, which made node locations unreliable with respect to the original document source. This restores the behavior that was present in v14.0.0, and was accidentally broken in v14.1.0. (bakkot)
• Fixed calling window.close() inside the Window's load event to no longer crash. (MattiasBuelens)

18.1.1

• Fixed connectedCallback to fire in situations involving document fragments, which was broken in v18.0.1. (GrantGryczan)

18.1.0

• Fixed headers.append() and headers.set() to normalize values. (MattiasBuelens)
• Fixed pageshow events to have bubbles: true and cancelable: true. (MattiasBuelens)
• Implemented the reason property on AbortSignals, along with the corresponding reason argument to abortSignal.abort() and AbortSignal.abort(). (MattiasBuelens)

18.0.1

• Fixed live Ranges to update correctly after calling node.normalize(). (hgiesel)
• Fixed live Ranges to update correctly after removing child nodes. (hgiesel)
• Fixed setting inputEl.valueAsDate = null to no longer throw an exception, but instead set the value to the empty string. (simon-weimann)
• Improved performance of node insertion and node.contains(). (GrantGryczan)

18.0.0

... (truncated)

Commits

• 22f7c3c Version 20.0.3
• c540630 Update dependencies and dev dependencies
• cdf07a1 Slight tweaks to GitHub Actions
• bd77578 Try to make the issue template clearer
• e285763 Version 20.0.2
• cb4e454 Change how the custom element registry is looked up
• f4324ba Fix event.getModifierState() and modifier property interaction
• fea788b Fix xhr.abort() when the XHR is invalid
• c3c421c Remove outdated comment
• df8de00 Version 20.0.1
• Additional commits viewable in compare view

Updates expo-module-scripts from 2.0.0 to 3.0.11

Commits

• See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) You can disable automated security fix PRs for this repo from the [Security Alerts page](https://github.com/customerio/customerio-expo-plugin/network/alerts).

[github-actions[bot]]

Pull request title looks good 👍!

If this pull request gets merged, it will not cause a new release of the software. Example: If this project's latest release version is 1.0.0. If this pull request gets merged in, the next release of this project will be 1.0.0. This pull request is not a breaking change.

All merged pull requests will eventually get deployed. But some types of pull requests will trigger a deployment (such as features and bug fixes) while some pull requests will wait to get deployed until a later time.

This project uses a special format for pull requests titles. Expand this section to learn more (expand by clicking the ᐅ symbol on the left side of this sentence)...

This project uses a special format for pull requests titles. Don't worry, it's easy! This pull request title should be in this format: ``` : short description of change being made ``` **If your pull request [introduces breaking changes](https://web.archive.org/web/20220725195319/https://nordicapis.com/what-are-breaking-changes-and-how-do-you-avoid-them/)** to the code, use this format: ``` !: short description of breaking change ``` where `` is one of the following: - `feat:` - A feature is being added or modified by this pull request. Use this if you made any changes to any of the features of the project. - `fix:` - A bug is being fixed by this pull request. Use this if you made any fixes to bugs in the project. - `docs:` - This pull request is making documentation changes, only. - `refactor:` - A change was made that doesn't fix a bug or add a feature. - `test:` - Adds missing tests or fixes broken tests. - `style:` - Changes that do not effect the code (whitespace, linting, formatting, semi-colons, etc) - `perf:` - Changes improve performance of the code. - `build:` - Changes to the build system (maven, npm, gulp, etc) - `ci:` - Changes to the CI build system (Travis, GitHub Actions, Circle, etc) - `chore:` - Other changes to project that don't modify source code or test files. - `revert:` - Reverts a previous commit that was made. ### Examples: ``` feat: edit profile photo refactor!: remove deprecated v1 endpoints build: update npm dependencies style: run formatter ``` Need more examples? Want to learn more about this format? [Check out the official docs](https://www.conventionalcommits.org/). **Note:** If your pull request does multiple things such as adding a feature _and_ makes changes to the CI server _and_ fixes some bugs then you might want to consider splitting this pull request up into multiple smaller pull requests.

[github-actions[bot]]

Pull request title looks good 👍!

If this pull request gets merged, it will not cause a new release of the software. Example: If this project's latest release version is 1.0.0. If this pull request gets merged in, the next release of this project will be 1.0.0. This pull request is not a breaking change.

All merged pull requests will eventually get deployed. But some types of pull requests will trigger a deployment (such as features and bug fixes) while some pull requests will wait to get deployed until a later time.

This project uses a special format for pull requests titles. Expand this section to learn more (expand by clicking the ᐅ symbol on the left side of this sentence)...

This project uses a special format for pull requests titles. Don't worry, it's easy! This pull request title should be in this format: ``` : short description of change being made ``` **If your pull request [introduces breaking changes](https://web.archive.org/web/20220725195319/https://nordicapis.com/what-are-breaking-changes-and-how-do-you-avoid-them/)** to the code, use this format: ``` !: short description of breaking change ``` where `` is one of the following: - `feat:` - A feature is being added or modified by this pull request. Use this if you made any changes to any of the features of the project. - `fix:` - A bug is being fixed by this pull request. Use this if you made any fixes to bugs in the project. - `docs:` - This pull request is making documentation changes, only. - `refactor:` - A change was made that doesn't fix a bug or add a feature. - `test:` - Adds missing tests or fixes broken tests. - `style:` - Changes that do not effect the code (whitespace, linting, formatting, semi-colons, etc) - `perf:` - Changes improve performance of the code. - `build:` - Changes to the build system (maven, npm, gulp, etc) - `ci:` - Changes to the CI build system (Travis, GitHub Actions, Circle, etc) - `chore:` - Other changes to project that don't modify source code or test files. - `revert:` - Reverts a previous commit that was made. ### Examples: ``` feat: edit profile photo refactor!: remove deprecated v1 endpoints build: update npm dependencies style: run formatter ``` Need more examples? Want to learn more about this format? [Check out the official docs](https://www.conventionalcommits.org/). **Note:** If your pull request does multiple things such as adding a feature _and_ makes changes to the CI server _and_ fixes some bugs then you might want to consider splitting this pull request up into multiple smaller pull requests.

[github-actions[bot]]

Hey, there @dependabot[bot] 👋🤖. I'm a bot here to help you.

⚠️ Pull requests into the branch beta typically only allows changes with the types: fix. From the pull request title, the type of change this pull request is trying to complete is: chore. ⚠️

This pull request might still be allowed to be merged. However, you might want to consider make this pull request merge into a different branch other then beta.

This project uses a special format for pull requests titles. Expand this section to learn more (expand by clicking the ᐅ symbol on the left side of this sentence)...

This project uses a special format for pull requests titles. Don't worry, it's easy! This pull request title should be in this format: ``` : short description of change being made ``` **If your pull request [introduces breaking changes](https://web.archive.org/web/20220725195319/https://nordicapis.com/what-are-breaking-changes-and-how-do-you-avoid-them/)** to the code, use this format: ``` !: short description of breaking change ``` where `` is one of the following: - `feat:` - A feature is being added or modified by this pull request. Use this if you made any changes to any of the features of the project. - `fix:` - A bug is being fixed by this pull request. Use this if you made any fixes to bugs in the project. - `docs:` - This pull request is making documentation changes, only. - `refactor:` - A change was made that doesn't fix a bug or add a feature. - `test:` - Adds missing tests or fixes broken tests. - `style:` - Changes that do not effect the code (whitespace, linting, formatting, semi-colons, etc) - `perf:` - Changes improve performance of the code. - `build:` - Changes to the build system (maven, npm, gulp, etc) - `ci:` - Changes to the CI build system (Travis, GitHub Actions, Circle, etc) - `chore:` - Other changes to project that don't modify source code or test files. - `revert:` - Reverts a previous commit that was made. ### Examples: ``` feat: edit profile photo refactor!: remove deprecated v1 endpoints build: update npm dependencies style: run formatter ``` Need more examples? Want to learn more about this format? [Check out the official docs](https://www.conventionalcommits.org/). **Note:** If your pull request does multiple things such as adding a feature _and_ makes changes to the CI server _and_ fixes some bugs then you might want to consider splitting this pull request up into multiple smaller pull requests.

[github-actions[bot]]

Hey, there @dependabot[bot] 👋🤖. I'm a bot here to help you.

⚠️ Pull requests into the branch beta typically only allows changes with the types: fix. From the pull request title, the type of change this pull request is trying to complete is: chore. ⚠️

This pull request might still be allowed to be merged. However, you might want to consider make this pull request merge into a different branch other then beta.

This project uses a special format for pull requests titles. Expand this section to learn more (expand by clicking the ᐅ symbol on the left side of this sentence)...

This project uses a special format for pull requests titles. Don't worry, it's easy! This pull request title should be in this format: ``` : short description of change being made ``` **If your pull request [introduces breaking changes](https://web.archive.org/web/20220725195319/https://nordicapis.com/what-are-breaking-changes-and-how-do-you-avoid-them/)** to the code, use this format: ``` !: short description of breaking change ``` where `` is one of the following: - `feat:` - A feature is being added or modified by this pull request. Use this if you made any changes to any of the features of the project. - `fix:` - A bug is being fixed by this pull request. Use this if you made any fixes to bugs in the project. - `docs:` - This pull request is making documentation changes, only. - `refactor:` - A change was made that doesn't fix a bug or add a feature. - `test:` - Adds missing tests or fixes broken tests. - `style:` - Changes that do not effect the code (whitespace, linting, formatting, semi-colons, etc) - `perf:` - Changes improve performance of the code. - `build:` - Changes to the build system (maven, npm, gulp, etc) - `ci:` - Changes to the CI build system (Travis, GitHub Actions, Circle, etc) - `chore:` - Other changes to project that don't modify source code or test files. - `revert:` - Reverts a previous commit that was made. ### Examples: ``` feat: edit profile photo refactor!: remove deprecated v1 endpoints build: update npm dependencies style: run formatter ``` Need more examples? Want to learn more about this format? [Check out the official docs](https://www.conventionalcommits.org/). **Note:** If your pull request does multiple things such as adding a feature _and_ makes changes to the CI server _and_ fixes some bugs then you might want to consider splitting this pull request up into multiple smaller pull requests.

[dependabot[bot]]

OK, I won't notify you again about this release, but will get in touch when a new version is available.

If you change your mind, just re-open this PR and I'll resolve any conflicts on it.