## Description

Recently `FooterComponent` was introduced for internal reasons, however
it hasn't been exported on web
leading to issues.

> [!caution]
> We need to set up CI for web...

Fixes #2534

## Changes

`FooterComponent` is now exported from `ScreenFooter.web.tsx`

## Test code and steps to reproduce

??? We do not have a web example - we need to add it.

## Checklist

- [ ] Included code example that can be used to test this change
- [ ] Updated TS types
- [ ] Updated documentation: <!-- For adding new props to native-stack
-->
- [ ]
https://github.com/software-mansion/react-native-screens/blob/main/guides/GUIDE_FOR_LIBRARY_AUTHORS.md
- [ ]
https://github.com/software-mansion/react-native-screens/blob/main/native-stack/README.md
- [ ]
https://github.com/software-mansion/react-native-screens/blob/main/src/types.tsx
- [ ]
https://github.com/software-mansion/react-native-screens/blob/main/src/native-stack/types.tsx
- [ ] Ensured that CI passes

## Description

It has been reported that there are project configurations in which
"$projectDir/../node_modules/react-native" exists, but node module
resolution algorithm
fails to find it. I've reintroduced the aforementioned location.


## Test code and steps to reproduce

Our examples should keep working as always ^^

## Checklist

- [ ] Included code example that can be used to test this change
- [ ] Updated TS types
- [ ] Updated documentation: <!-- For adding new props to native-stack
-->
- [ ]
https://github.com/software-mansion/react-native-screens/blob/main/guides/GUIDE_FOR_LIBRARY_AUTHORS.md
- [ ]
https://github.com/software-mansion/react-native-screens/blob/main/native-stack/README.md
- [ ]
https://github.com/software-mansion/react-native-screens/blob/main/src/types.tsx
- [ ]
https://github.com/software-mansion/react-native-screens/blob/main/src/native-stack/types.tsx
- [ ] Ensured that CI passes

…2552)

## Description

> [!note]
> This issue seems to concern only old architecture. See below for
description of Fabric situation 👇🏻

This PR aims to fix a bug described below 👇🏻 and at the same time
balancing on the thin edge of not introducing regressions regarding:
#2316, #2248, #2385.

### Bug description

See `Test2552`. 

The flow is as follows: 

1. we have tab navigator with nested stack navigators on each tab (A &
B),
2. In `useLayoutEffect` we schedule a timer which callback changing the
subview elements,
3. before the timer fires we change the tab from A to B,
4. wait few seconds fot timer to fire,
5. go back to A,
6. notice that the subviews are laid out incorrectly (video below 👇🏻)


https://github.com/user-attachments/assets/2bf621a7-efd4-44cf-95e1-45a46e425f07


Basically what happens is we're sending `layoutIfNeeded` to navigation
bar before subviews are mounted under navigation bar view hierarchy.
This causes "isLayoutDirty" flags to be cleaned up and subsequent
`layoutIfNeeded` messages have no effect.

## Changes

We now wait with triggering layout for the subview to be attached to
window.

> [!note]
> TODO: possibly we should call the layout from `didMoveToWindow` but I
haven't found the case it does not work without the call, so I'm not
adding it for now.

> [!note]
> Calling layout on whole navigation bar for every subview update seems
wrong, however the change is subview change can have effect on other
neighbouring views (e.g. long title which need to be truncated) & it
seems that we need to do this. Maybe we could get away will requesting
it only from UINavigationBarContentView skipping few levels, but this is
left for consideration in the future.

> [!important]
> I do not understand why we need to send `layoutIfNeeded` and
`setNeedsLayout` is not enough, but not sending the former results in
regressions in Test432. Leaving it for future considerations.

### Fabric 

The strategy with setting screen options inside timer nested in
useLayoutEffect seems to not work at all on new architecture. My
impression is that the timer gets cancelled every time the screen loses
focus (tab is changed). I do not know whether this is a bug on our side,
or maybe it should work this way or it is Fabric bug. This should be
debugged in future.


## Test code and steps to reproduce

Test2552 - Follows the steps described above ☝🏻 

Test432 - Follow the steps from issues described in mentioned issues
:point_up:

## Checklist

- [ ] Included code example that can be used to test this change
- [ ] Updated TS types
- [ ] Updated documentation: <!-- For adding new props to native-stack
-->
- [ ]
https://github.com/software-mansion/react-native-screens/blob/main/guides/GUIDE_FOR_LIBRARY_AUTHORS.md
- [ ]
https://github.com/software-mansion/react-native-screens/blob/main/native-stack/README.md
- [ ]
https://github.com/software-mansion/react-native-screens/blob/main/src/types.tsx
- [ ]
https://github.com/software-mansion/react-native-screens/blob/main/src/native-stack/types.tsx
- [ ] Ensured that CI passes

#2553)

## Description

I was just writing #2552 and got confused that the header config
subviews are added as subviews to the header config view
in host tree, before they are attached to the navigation bar view
hierarchy. This transient state does not make any sense,
and we do not do similar thing on Fabric.

## Changes

`self.superview` returns now `nil` until the subview is mounted in
navigation bar view hierarchy.

Also moved the function to Paper specific section of file, because it is
not called on Fabric on any codepath.

## Test code and steps to reproduce

We haven't used this behaviour. There should be no regression in text
examples.

## Checklist

- [ ] Included code example that can be used to test this change
- [ ] Updated TS types
- [ ] Updated documentation: <!-- For adding new props to native-stack
-->
- [ ]
https://github.com/software-mansion/react-native-screens/blob/main/guides/GUIDE_FOR_LIBRARY_AUTHORS.md
- [ ]
https://github.com/software-mansion/react-native-screens/blob/main/native-stack/README.md
- [ ]
https://github.com/software-mansion/react-native-screens/blob/main/src/types.tsx
- [ ]
https://github.com/software-mansion/react-native-screens/blob/main/src/native-stack/types.tsx
- [ ] Ensured that CI passes

## Description

This PR bumps RN developement version in the library from 0.72 to 0.76 &
updates eslint configuration & few other development packages. Please
note the changes in gesture-handler related types from Screen Transition
API.

These changes are motivated by the fact that I've recently bumped
versions of language servers in my editor & eslint language server
started throwing errors in our example apps (when editing `apps/**`
files) that is does not know anything about `@react-native` config we
try to extend in `apps/.eslintrc.js`. This makes absolute sense, as it
had tried to found the `@react-native` config with "standard module
resolution algorithm", and there were no node_modules containing the
config above `apps` directory. During fixing this I've also noticed
errors in configuration of our root-level `.eslintrc` file.

I've decided to fix this and bump dependencies, so that my eyes don't
hurt from red screen when developing.

## Changes

☝🏻 

I've also described important changes in "review" below 👇🏻 

## Test code and steps to reproduce

I've modified only development dependencies, therefore behaviour for
end-user should not change in any way. Our apps should now work & eslint
config should be improved.

## Checklist

- [ ] Ensured that CI passes

…entation (#2562)

## Description

Noticed a low-hanging opportunity to simplify this method while doing
something different.
We already had this loop implemented in helper function so we could use
it.

## Test code and steps to reproduce

CI should be enough

## Checklist

- [ ] Ensured that CI passes

## Description

Fixes #2550

Empirical research shows that UIKit uses
`interruptibleAnimatorForTransition:` method on
`UIViewAnimatedTransitioning` (our `RNSStackAnimator`)
for navigation item animation. This allowed us customizing navigation
item timing curve & animation style, however it has caused unexpected
content jumps (see #2550 or video below 👇).

> [!important]
> This PR reverts changes to navigation item animation introduced with
v4. I guess it could be considered breaking unless it weren't a bit
broken => I'm treating this as a necessary fix
> & will try to bring back "new behaviour" soon, once we figure why
`interruptibleAnimatorForTransition:` causes such bugs.


https://github.com/user-attachments/assets/000fa79d-b01a-4261-941b-c5922e0d17f6

After the changes this looks as follows:




https://github.com/user-attachments/assets/42870bab-304e-4a9d-b253-42d94c6159e7



## Changes

- **Add reproduction**
- **Do not override `interruptibleAnimatorForTransition:` preventing
content jump**

## Test code and steps to reproduce

`TestAnimation`

## Checklist

- [x] Included code example that can be used to test this change
- [ ] Ensured that CI passes

## Description

We recommended to run `yarn prepare` in `react-navigation` submodule,
which is not existend (for some time now I believe).

## Changes

Updated the `yarn submodules` script & fixed the contributing guide.


## Test code and steps to reproduce

Clone fresh repo & follow contributing guide - it should work now. 

## Checklist

- [ ] Ensured that CI passes

## Description

Fixes #2525

View hierarchy for modal with header looks kinda like this:

`UITransitionView` -> `Screen` -> `Stack` (`UINavigationController`) ->
`Screen` -> content

calling `[_controller dismissViewControllerAnimated:YES completion:nil]`
on the `Stack` ☝️, according to
[documentation](https://developer.apple.com/documentation/uikit/uiviewcontroller/dismiss(animated:completion:)?language=objc)
should dismiss the view controller itself and any view controllers
presented from that view controller. However in practive it dismisses
not only itself and "above" modal, but also a single modal "below". I'm
not sure
why it is the case. Removing this line of code introduces a bug: during
development, when multiple modals are opened and you reload the
react-native, the modals could be left in stuck state. I'll proceed, as
this bug
bug in development is of much lesser severity. 

I've decided to move the call "one up" the view controller hierarchy, to
avoid calling dismiss directly on UINavigationController as it looks
like it causes the problem. This fixes the problem & keeps the
development behaviour working as intended.

## Changes

Described above ☝️

## Test code and steps to reproduce

I've enhanced `TestModalNavigation` test case to cover this issue. 

## Checklist

- [x] Included code example that can be used to test this change
- [ ] Ensured that CI passes

Fixed #2557. We
have to take preloaded screens into account when freezing screens. Till
now, the assumption was that the newest screens are the ones rendered,
right now top children can be the preloaded ones, so we have to filter
them from calculating the size of frozen screens. We could also think of
freezing the preloaded screens, wdyt about it @satya164 ?

## Description

There is still some header animation noticeable for some reason. <--
This is because we use `fade` transition with duration 0 and do not
override interruptible animator! To prevent the animation we could
either return `nil` interruptible animator (but overriding the method
comes with it's own set of problems, see #2563 and other related) or
handle the `none` animation much earlier, when calling
`showViewControllers:animated:` in `updateContainer` (pass `animated:
NO`).

PS: If we would want to pass `animated: NO` I wonder what would happen
to dismiss prevention - we implemented it at the stage of the animation
start... We need to think this through.

Note: Must be implemented with old animation API, because
`UIViewPropertyAnimator` does not allow for 0 duration (it uses default
if the specified animation duration is below some undocumented
treshold).

This regression was introduced with #2477 

## Changes

We now use old API for `animation: none` & still rely on fade animation
to implement it. Note the points made above ☝🏻 - we should refactor this
code to make advantage of `animated:` parameter of the
`showViewControllers:animated:`.

## Test code and steps to reproduce

`TestAnimation` - set stack presentation to `none` - it works as prior
to v4.

WIP VIDEO

## Checklist

- [ ] Included code example that can be used to test this change
- [ ] Updated TS types
- [ ] Updated documentation: <!-- For adding new props to native-stack
-->
- [ ]
https://github.com/software-mansion/react-native-screens/blob/main/guides/GUIDE_FOR_LIBRARY_AUTHORS.md
- [ ]
https://github.com/software-mansion/react-native-screens/blob/main/native-stack/README.md
- [ ]
https://github.com/software-mansion/react-native-screens/blob/main/src/types.tsx
- [ ]
https://github.com/software-mansion/react-native-screens/blob/main/src/native-stack/types.tsx
- [ ] Ensured that CI passes

## Description

Add a newly introduced field `ios.componentProvider` to the `codegen`
configuration to create an association map between JS components and
their native implementations.

See more information here:
software-mansion/react-native-svg#2572

## Changes

- added `codegenConfig.ios.componentProvider` field to package.json

### Before

```objc

Class<RCTComponentViewProtocol> RCTThirdPartyFabricComponentsProvider(const char *name) {
  static std::unordered_map<std::string, Class (*)(void)> sFabricComponentsClassMap = {
    // ...
    {"RNSFullWindowOverlay", RNSFullWindowOverlayCls}, // 3
    {"RNSModalScreen", RNSModalScreenCls}, // 3
    {"RNSScreenContainer", RNSScreenContainerCls}, // 3
    {"RNSScreenContentWrapper", RNSScreenContentWrapperCls}, // 3
    {"RNSScreenFooter", RNSScreenFooterCls}, // 3
    {"RNSScreen", RNSScreenCls}, // 3
    {"RNSScreenNavigationContainer", RNSScreenNavigationContainerCls}, // 3
    {"RNSScreenStackHeaderConfig", RNSScreenStackHeaderConfigCls}, // 3
    {"RNSScreenStackHeaderSubview", RNSScreenStackHeaderSubviewCls}, // 3
    {"RNSScreenStack", RNSScreenStackCls}, // 3
    {"RNSSearchBar", RNSSearchBarCls}, // 3
    // ...
```
### After

```objc
@implementation RCTThirdPartyComponentsProvider

+ (NSDictionary<NSString *, Class<RCTComponentViewProtocol>> *)thirdPartyFabricComponents
{
  return @{
		@"RNSFullWindowOverlay": NSClassFromString(@"RNSFullWindowOverlay"), // react-native-screens
		@"RNSModalScreen": NSClassFromString(@"RNSModalScreen"), // react-native-screens
		@"RNSScreenContainer": NSClassFromString(@"RNSScreenContainer"), // react-native-screens
		@"RNSScreenContentWrapper": NSClassFromString(@"RNSScreenContentWrapper"), // react-native-screens
		@"RNSScreenFooter": NSClassFromString(@"RNSScreenFooter"), // react-native-screens
		@"RNSScreen": NSClassFromString(@"RNSScreen"), // react-native-screens
		@"RNSScreenNavigationContainer": NSClassFromString(@"RNSScreenNavigationContainer"), // react-native-screens
		@"RNSScreenStackHeaderConfig": NSClassFromString(@"RNSScreenStackHeaderConfig"), // react-native-screens
		@"RNSScreenStackHeaderSubview": NSClassFromString(@"RNSScreenStackHeaderSubview"), // react-native-screens
		@"RNSScreenStack": NSClassFromString(@"RNSScreenStack"), // react-native-screens
		@"RNSSearchBar": NSClassFromString(@"RNSSearchBar"), // react-native-screens
  };
}
```

## Test code and steps to reproduce

Run `pod install` in React Native 0.77 app and see
`RCTThirdPartyFabricComponentsProvider` to check the content

## Description

#2567 introduced `ios.componentProvider` field to package definition -
and that's fine, but we're pointing to wrong names there.

## Changes

Updated the names to existing symbol names. 


## Test code and steps to reproduce

This caused runtime errors when running the app on 0.77. I need this
commit for the #2581 (0.77 support)

## Checklist

- [ ] Included code example that can be used to test this change
- [ ] Updated TS types
- [ ] Updated documentation: <!-- For adding new props to native-stack
-->
- [ ]
https://github.com/software-mansion/react-native-screens/blob/main/guides/GUIDE_FOR_LIBRARY_AUTHORS.md
- [ ]
https://github.com/software-mansion/react-native-screens/blob/main/native-stack/README.md
- [ ]
https://github.com/software-mansion/react-native-screens/blob/main/src/types.tsx
- [ ]
https://github.com/software-mansion/react-native-screens/blob/main/src/native-stack/types.tsx
- [ ] Ensured that CI passes