chore: reformat source using prettier (#1550)

* chore: reformat source using prettier
* chore: fix lint

Author: mdjastrzebski

.editorconfig

@@ -0,0 +1,17 @@
+# EditorConfig helps developers define and maintain consistent
+# coding styles between different editors and IDEs
+# editorconfig.org
+
+root = true
+
+[*]
+
+indent_style = space
+indent_size = 2
+
+end_of_line = lf
+charset = utf-8
+trim_trailing_whitespace = true
+insert_final_newline = true
+
+max_line_length = 100

.eslintrc

@@ -6,10 +6,7 @@
     "no-console": 1,
     "react/no-multi-comp": 0,
     // Ignore certain webpack alias because it can't be resolved
-    "import/no-unresolved": [
-      2,
-      { "ignore": ["^@theme", "^@docusaurus", "^@generated"] }
-    ],
+    "import/no-unresolved": [2, { "ignore": ["^@theme", "^@docusaurus", "^@generated"] }],
     "react-native/no-color-literals": "off",
     "react-native/no-inline-styles": "off",
     "react-native-a11y/has-valid-accessibility-descriptors": "off",

.github/ISSUE_TEMPLATE/feature_request.md

@@ -5,10 +5,13 @@ labels: 'feature request'
 ---
 
 ## Describe the Feature
+
 <!-- Describe the requested Feature -->
 
 ## Possible Implementations
+
 <!-- Describe how to implement the feature -->
 
 ## Related Issues
+
 <!-- Link related issues here -->

.github/dependabot.yml

@@ -1,10 +1,10 @@
 version: 2
 updates:
-- package-ecosystem: npm
-  directory: "/"
-  schedule:
-    interval: "weekly"
-  open-pull-requests-limit: 3
-  ignore:
-    - dependency-name: "*"
-      update-types: ["version-update:semver-minor", "version-update:semver-patch"]
+  - package-ecosystem: npm
+    directory: '/'
+    schedule:
+      interval: 'weekly'
+    open-pull-requests-limit: 3
+    ignore:
+      - dependency-name: '*'
+        update-types: ['version-update:semver-minor', 'version-update:semver-patch']

.prettierrc.js

@@ -1,5 +1,5 @@
 // added for Jest inline snapshots to not use default Prettier config
 module.exports = {
   singleQuote: true,
-  trailingComma: "es5"
-}
+  trailingComma: 'es5',
+};

CODE_OF_CONDUCT.md

@@ -14,21 +14,21 @@ orientation.
 Examples of behavior that contributes to creating a positive environment
 include:
 
-* Using welcoming and inclusive language
-* Being respectful of differing viewpoints and experiences
-* Gracefully accepting constructive criticism
-* Focusing on what is best for the community
-* Showing empathy towards other community members
+- Using welcoming and inclusive language
+- Being respectful of differing viewpoints and experiences
+- Gracefully accepting constructive criticism
+- Focusing on what is best for the community
+- Showing empathy towards other community members
 
 Examples of unacceptable behavior by participants include:
 
-* The use of sexualized language or imagery and unwelcome sexual attention or
+- The use of sexualized language or imagery and unwelcome sexual attention or
   advances
-* Trolling, insulting/derogatory comments, and personal or political attacks
-* Public or private harassment
-* Publishing others' private information, such as a physical or electronic
+- Trolling, insulting/derogatory comments, and personal or political attacks
+- Public or private harassment
+- Publishing others' private information, such as a physical or electronic
   address, without explicit permission
-* Other conduct which could reasonably be considered inappropriate in a
+- Other conduct which could reasonably be considered inappropriate in a
   professional setting
 
 ## Our Responsibilities

examples/basic/App.tsx

@@ -8,11 +8,7 @@ const App = () => {
 
   return (
     <SafeAreaView>
-      {user == null ? (
-        <LoginForm onLoginSuccess={setUser} />
-      ) : (
-        <Home user={user} />
-      )}
+      {user == null ? <LoginForm onLoginSuccess={setUser} /> : <Home user={user} />}
     </SafeAreaView>
   );
 };

examples/basic/__tests__/App.test.tsx

@@ -13,9 +13,7 @@ test('renders correctly', () => {
 
   // Idiom: `getBy*` queries are predicates by themselves, but we will use it with `expect().toBeOnTheScreen()`
   // to clarify our intent.
-  expect(
-    screen.getByRole('header', { name: 'Sign in to Example App' })
-  ).toBeOnTheScreen();
+  expect(screen.getByRole('header', { name: 'Sign in to Example App' })).toBeOnTheScreen();
 });
 
 /**
@@ -32,9 +30,7 @@ test('User can sign in successully with correct credentials', async () => {
 
   // Idiom: `getBy*` queries are predicates by themselves, but we will use it with `expect().toBeOnTheScreen()`
   // to clarify our intent.
-  expect(
-    screen.getByRole('header', { name: 'Sign in to Example App' })
-  ).toBeOnTheScreen();
+  expect(screen.getByRole('header', { name: 'Sign in to Example App' })).toBeOnTheScreen();
 
   // Hint: we can use `getByLabelText` to find our text inputs using their labels.
   await user.type(screen.getByLabelText('Username'), 'admin');
@@ -47,14 +43,10 @@ test('User can sign in successully with correct credentials', async () => {
   // for the action to complete.
   // Hint: subsequent queries do not need to use `findBy*`, because they are used after the async action
   // already finished
-  expect(
-    await screen.findByRole('header', { name: 'Welcome admin!' })
-  ).toBeOnTheScreen();
+  expect(await screen.findByRole('header', { name: 'Welcome admin!' })).toBeOnTheScreen();
 
   // Idiom: use `queryBy*` with `expect().not.toBeOnTheScreen()` to assess that element is not present.
-  expect(
-    screen.queryByRole('header', { name: 'Sign in to Example App' })
-  ).not.toBeOnTheScreen();
+  expect(screen.queryByRole('header', { name: 'Sign in to Example App' })).not.toBeOnTheScreen();
   expect(screen.queryByLabelText('Username')).not.toBeOnTheScreen();
   expect(screen.queryByLabelText('Password')).not.toBeOnTheScreen();
 });
@@ -75,22 +67,16 @@ test('User will see errors for incorrect credentials', async () => {
   const user = userEvent.setup();
   render(<App />);
 
-  expect(
-    screen.getByRole('header', { name: 'Sign in to Example App' })
-  ).toBeOnTheScreen();
+  expect(screen.getByRole('header', { name: 'Sign in to Example App' })).toBeOnTheScreen();
 
   await user.type(screen.getByLabelText('Username'), 'admin');
   await user.type(screen.getByLabelText('Password'), 'qwerty123');
   await user.press(screen.getByRole('button', { name: 'Sign In' }));
 
   // Hint: you can use custom Jest Native matcher to check text content.
-  expect(await screen.findByRole('alert')).toHaveTextContent(
-    'Incorrect username or password'
-  );
+  expect(await screen.findByRole('alert')).toHaveTextContent('Incorrect username or password');
 
-  expect(
-    screen.getByRole('header', { name: 'Sign in to Example App' })
-  ).toBeOnTheScreen();
+  expect(screen.getByRole('header', { name: 'Sign in to Example App' })).toBeOnTheScreen();
   expect(screen.getByLabelText('Username')).toBeOnTheScreen();
   expect(screen.getByLabelText('Password')).toBeOnTheScreen();
 });
@@ -102,9 +88,7 @@ test('User can sign in after incorrect attempt', async () => {
   const user = userEvent.setup();
   render(<App />);
 
-  expect(
-    screen.getByRole('header', { name: 'Sign in to Example App' })
-  ).toBeOnTheScreen();
+  expect(screen.getByRole('header', { name: 'Sign in to Example App' })).toBeOnTheScreen();
 
   const usernameInput = screen.getByLabelText('Username');
   const passwordInput = screen.getByLabelText('Password');
@@ -113,9 +97,7 @@ test('User can sign in after incorrect attempt', async () => {
   await user.type(passwordInput, 'qwerty123');
   await user.press(screen.getByRole('button', { name: 'Sign In' }));
 
-  expect(await screen.findByRole('alert')).toHaveTextContent(
-    'Incorrect username or password'
-  );
+  expect(await screen.findByRole('alert')).toHaveTextContent('Incorrect username or password');
 
   // Clear password field
   await user.clear(passwordInput);
@@ -124,9 +106,7 @@ test('User can sign in after incorrect attempt', async () => {
   await user.press(screen.getByRole('button', { name: 'Sign In' }));
 
   expect(await screen.findByText('Welcome admin!')).toBeOnTheScreen();
-  expect(
-    screen.queryByRole('header', { name: 'Sign in to Example App' })
-  ).not.toBeOnTheScreen();
+  expect(screen.queryByRole('header', { name: 'Sign in to Example App' })).not.toBeOnTheScreen();
   expect(screen.queryByLabelText('Username')).not.toBeOnTheScreen();
   expect(screen.queryByLabelText('Password')).not.toBeOnTheScreen();
 });

examples/basic/components/LoginForm.tsx

@@ -1,12 +1,5 @@
 import * as React from 'react';
-import {
-  StyleSheet,
-  View,
-  Text,
-  TextInput,
-  Pressable,
-  ActivityIndicator,
-} from 'react-native';
+import { StyleSheet, View, Text, TextInput, Pressable, ActivityIndicator } from 'react-native';
 
 type Props = {
   onLoginSuccess: (user: string) => void;
@@ -84,10 +77,7 @@ export function LoginForm({ onLoginSuccess }: Props) {
  * @param password The password to authenticate.
  * @returns username if the username and password are correct, null otherwise.
  */
-async function authUser(
-  username: string,
-  password: string
-): Promise<string | null> {
+async function authUser(username: string, password: string): Promise<string | null> {
   return new Promise((resolve) =>
     setTimeout(() => {
       const hasValidCredentials = username === 'admin' && password === 'admin1';

examples/react-navigation/README.md

@@ -7,10 +7,10 @@ This example shows how to write integration tests using React Navigation without
 ## Recommended tests
 
 There are two types of recommeded tests:
+
 1. Tests operating on navigator level - these use `renderNavigator` helper to render a navigator component used in the app. It is useful when you want to test a scenario that includes multiple screens.
 2. Tests operating on single screen level - these use regular `render` helper but require refactoring screen components into `Screen` and `ScreenContent` components. Where `Screen` receives React Navigation props and/or uses hooks like `useNavigation` while `ScreenContent` does not have a direct relation to React Navigation API but gets props from `Screen` and calls relevant callbacks to trigger navigation.
 
 ## Non-recommended tests
 
-There also exists another popular type of screen level tests, where users mock React Navigation objects like `navigation`, `route` and/or hooks like  `useNavigation`, etc. We don't recommend this way of testing. **Mocking internal parts of the libraries is effectively testing implementation details, which goes against the Testing Library's [Guiding Principles](https://testing-library.com/docs/guiding-principles/)**.
-
+There also exists another popular type of screen level tests, where users mock React Navigation objects like `navigation`, `route` and/or hooks like `useNavigation`, etc. We don't recommend this way of testing. **Mocking internal parts of the libraries is effectively testing implementation details, which goes against the Testing Library's [Guiding Principles](https://testing-library.com/docs/guiding-principles/)**.