I've just taken notice of @Simek awesome work on the auto-generation doc feature, so I might as well update the whole package's doc comments to be compatible with his feature.

Hi @FelipeACP, currently the docs auto-gen feature is still in development phase and there is no public guide yet how to add it to the package. I will try to condense the information and will try to list all the required steps below:

• add package mappings to the GenerateDocsAPIData.ts in tools directory
• setup Expo tools and run et gdad or et gdad -p PACKAGE_|NAME_IN_MAPPINGS anywhere from the workspace
• verify that new JSON file has been generated in docs/public directory
• import and use APISection component on the unversioned MD for the package
• verify that there are no regression/missing information in comparision to hand-written guide and all types are exported and have the correct types

Hope those few steps will help you to achieve the goal described above. Feel free to ask any related questions, if you would have any. 🙂

Summary

Closes https://github.com/facebook/jest/issues/11565

Defaulting to 60fps target for animation frames which matches jsdom.

Test plan

• [ ] CI green

Summary

Authorization hangs and an app_cancel error is thrown. When the application asks for the fingerprint, then we lock the screen and unlock it using a pattern or a pin. After that each authenticateAsync call throws an app_cancel error. This issue does not happen every time.

I use Xiaomi Mi9.

It seems like there is a problem with Android implementation and property mIsAuthenticating is always true after case described above, thats why another call of authenticateAsync causes this error.

Managed or bare workflow? If you have ios/ or android/ directories in your project, the answer is bare!

bare

What platform(s) does this occur on?

Android

SDK Version (managed workflow only)

10.0.0

Environment

I use expo-local-authentication with unimodules.

Reproducible demo or steps to reproduce from a blank project

Look at summary.

It seems to be fixed by https://github.com/expo/expo/pull/13023. The patch will be released with the new SDK (42).

I'm closing this issue for now. However, feel free to reopen it, if this bug will still be present in the SDK 42.

I think it's a mistake in our documentation - not in type definitions. On Android, we provide more information with permission responses. That information isn't available on iOS, but we still need to ensure the type is correct for both platforms. That's why methods return LocationPermissionResponse.

@erights

Why the boolean flag? A compartment should be able to detect the templatedness of its own templates. It should not be able to detect the templatedness of other templates.

The templatedness check (without compartments) is realm-agnostic (https://github.com/tc39/proposal-array-is-template-object/issues/10) i.e. another Realm templates pass it, hence the new [[TemplateObject]] instead of reusing [[TemplateMap]] for the check. I agree moving the [[TemplateMap]] to the compartments from realms makes sense, but the regular (i.e. not compartmentalized) isTemplateObjectis not checking the [[TemplateMap]], so it doesn't change much?

I wanted to preserve this semantic for code running inside a Compartment. If this is not a requirement (and the code running inside a compartment will always be more restricted), then the signature could be changed. What is the expected behavior we're looking for in the following cases (for the Array.[prototype].isTemplateObject running inside a compartment)?

1. a cross-realm template
2. same-realm template a. created outside of compartment b. created in a different compartment c. created in the same compartment

IIUC 1, 2a and 2b should fail unconditionally, and 2c should look in the compartment-relative[[TemplateMap]], and additionally consult the configurable isTemplate? Do I get it right, that compartment.isTemplate is called implicitly for 2c?

If this is the case, we would need to know that the code executes in a compartment. It's not currently spelled out, but I guess compartments will store that in a running execution context so we could branch on that?

is there a summary of why this is needed?

@Jack-Works, see https://github.com/tc39/proposal-array-is-template-object/issues/10#issuecomment-771274276 and the rest of that issue. The summary is: to be able to virtualize isTemplateObject check in a compartment.

<!-- Thanks for submitting a pull request! Please provide enough information so that others can review your pull request. The two fields below are mandatory. -->

<!-- Please remember to update CHANGELOG.md at the root of the project if you have not done so. -->

Summary

See #8467.

When using toMatchInlineSnapshot(), the implicit dependency on prettier can be a source of confusion, so briefly adding a mention in the docs.

Test plan

<!-- Demonstrate the code is solid. Example: The exact commands you ran and their output, screenshots / videos if the pull request changes UI. -->

(Docs only.)

Why

Update docs

How

Test Plan

Checklist

• [ ] Documentation is up to date to reflect these changes (eg: https://docs.expo.io and README.md).
• [ ] This diff will work correctly for expo build (eg: updated @expo/xdl).
• [ ] This diff will work correctly for expo prebuild & EAS Build (eg: updated a module plugin).

1. **Generic** Restore the credentials (for managed projects it's done before `expo prebuild`):

Thanks for the quick response.

Legacy timers do not support rAF:

I'm not sure why waitFor from @testing-library/dom was working before merged https://github.com/testing-library/dom-testing-library/pull/966 though. Maybe it just worked incidentally because we used to real setImmediate which would flush animation frames at some point (even though the timing would be completely off)

PR welcome!

Let me check if I can throw something together quickly. Not sure if this will be useful though since that would still require updating jest itself.

there is already a PR for bumping flipper to 0.93 on IOS

https://github.com/facebook/react-native/pull/31708

<!-- Thank you for your pull request. Please provide a description above and review the requirements below. -->

Fixes #860

@siimon @zbjornson do you want to not be included here?

Note that 16.x on GH Actions will fail: https://github.com/siimon/prom-client/pull/436#issuecomment-832452127

Checklist

<!-- Remove items that do not apply. For completed items, change [ ] to [x]. -->

• [x] npm test passes
• [ ] tests are included
• [ ] documentation is changed or added
• [ ] contribution guidelines followed here

See https://github.com/siimon/prom-client/pull/436 and https://github.com/nodejs/node/issues/38412

New run: https://ci.nodejs.org/view/Node.js-citgm/job/citgm-smoker-pipeline/146/

I started a run (with citgm's main branch) against Node.js master to check the current status: https://ci.nodejs.org/view/Node.js-citgm/job/citgm-smoker/2643/