Merge pull request #155 from callstack/chore/tooling-overhaul

chore: tooling overhaul - integrated lefthook & commitlint, upgraded dependencies, formatted files, extracted tooling config from package.json

Author: artus9033

.eslintrc.json

@@ -0,0 +1,6 @@
+{
+  "root": true,
+  "extends": ["@react-native", "prettier"],
+  "plugins": ["prettier"],
+  "ignorePatterns": ["node_modules/", "lib/"]
+}

.github/workflows/build.yml

@@ -10,7 +10,7 @@ jobs:
   android:
     name: Build Android App
     runs-on: ubuntu-latest
-    
+
     env:
       SKIP_YARN_COREPACK_CHECK: 0
 
@@ -46,7 +46,7 @@ jobs:
   ios:
     name: Build iOS App
     runs-on: macos-latest
-    
+
     env:
       SKIP_YARN_COREPACK_CHECK: 0
 
@@ -85,4 +85,4 @@ jobs:
       - name: Build iOS App
         run: |
           cd example/swift
-          xcodebuild -workspace SwiftExample.xcworkspace -scheme SwiftExample -configuration Debug -sdk iphonesimulator -destination 'platform=iOS Simulator,name=iPhone 16' build CODE_SIGNING_ALLOWED=NO
+          xcodebuild -workspace SwiftExample.xcworkspace -scheme SwiftExample -configuration Debug -sdk iphonesimulator -destination 'platform=iOS Simulator,name=iPhone 16' build CODE_SIGNING_ALLOWED=NO

.github/workflows/ci.yml

@@ -2,9 +2,9 @@ name: Lint & Type Check
 
 on:
   push:
-    branches: [ main ]
+    branches: [main]
   pull_request:
-    branches: [ main ]
+    branches: [main]
 
 jobs:
   analyse:

.prettierignore

@@ -0,0 +1,2 @@
+node_modules
+lib

.prettierrc.json

@@ -0,0 +1,7 @@
+{
+  "quoteProps": "consistent",
+  "singleQuote": true,
+  "tabWidth": 2,
+  "trailingComma": "es5",
+  "useTabs": false
+}

.release-it.json

@@ -0,0 +1,18 @@
+{
+  "$schema": "https://unpkg.com/release-it@19/schema/release-it.json",
+  "git": {
+    "commitMessage": "chore: release ${version}",
+    "tagName": "v${version}"
+  },
+  "npm": {
+    "publish": true
+  },
+  "github": {
+    "release": true
+  },
+  "plugins": {
+    "@release-it/conventional-changelog": {
+      "preset": "angular"
+    }
+  }
+}

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
@@ -70,4 +70,4 @@ members of the project's leadership.
 This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
 available at https://www.contributor-covenant.org/version/1/4/code-of-conduct/
 
-[homepage]: https://www.contributor-covenant.org
+[homepage]: https://www.contributor-covenant.org

bob.config.js

@@ -0,0 +1,26 @@
+module.exports = {
+  source: 'src',
+  output: 'lib',
+  targets: [
+    [
+      'commonjs',
+      {
+        esm: true,
+        configFile: true,
+      },
+    ],
+    [
+      'module',
+      {
+        esm: true,
+        configFile: true,
+      },
+    ],
+    [
+      'typescript',
+      {
+        project: 'tsconfig.build.json',
+      },
+    ],
+  ],
+};

commitlint.config.js

@@ -0,0 +1 @@
+export default { extends: ['@commitlint/config-conventional'] };

docs/GUIDELINES.md

@@ -5,24 +5,24 @@ Here you can find the guidelines for standard brownfield approach and advanced u
 As a golden rule of standard brownfield with react-native, your native App should never have to interact directly
 with react-native APIs. There are various reasons that doing the opposite is discouraged.
 
-- If you have different teams working on RN brownfield and the native App and you distribute your AAR/XCFramework to the native 
-team. They can use the APIs from those artifacts and interact with them. However, if the native team have to import a react native
-API, say `PackageList` then the rule of brownfield is being violated. The native team have native developers and they should not need
-to worry about and interact with react-native directly. All of the abstraction should be handled within your artifacts.
+- If you have different teams working on RN brownfield and the native App and you distribute your AAR/XCFramework to the native
+  team. They can use the APIs from those artifacts and interact with them. However, if the native team have to import a react native
+  API, say `PackageList` then the rule of brownfield is being violated. The native team have native developers and they should not need
+  to worry about and interact with react-native directly. All of the abstraction should be handled within your artifacts.
 
 - If your native App interacts with react-native directly then you could imagine how complicated the codebase would be. The native App
-should follow and worry about their native APIs rather than interacting with react-native. If in future, some react-native APIs needs to
-be changed or refactored, then the effort would be cumbersome. On the contrast, if your native App was interacting with your artifact only
-then the native App need not to worry about what happens internally. This makes things simpler for the native App team.
+  should follow and worry about their native APIs rather than interacting with react-native. If in future, some react-native APIs needs to
+  be changed or refactored, then the effort would be cumbersome. On the contrast, if your native App was interacting with your artifact only
+  then the native App need not to worry about what happens internally. This makes things simpler for the native App team.
 
 - If the native App team is using your artifact and any build, compile time or run time issue arises the stack trace would lead to your artifact
-and making it simpler for the teams to focus on their area only. On the contrary, if the native App team would interact with react-native directly,
-then any related issues would be time consuming for that team to figure out the root cause and then delegate to the team managing RN flows.
+  and making it simpler for the teams to focus on their area only. On the contrary, if the native App team would interact with react-native directly,
+  then any related issues would be time consuming for that team to figure out the root cause and then delegate to the team managing RN flows.
 
 Building upon the above points, below is how your brownfield implementation should look like if you're using `react-native-brownfield`:
 
 - In your brownfield android library or iOS xcframework, create a class following the facade pattern. The role of this class would be to encapsulate the
-initialization of `react-native-brownfield` by not asking the native App to interact with `react-native` directly. Below is how it would look like:
+  initialization of `react-native-brownfield` by not asking the native App to interact with `react-native` directly. Below is how it would look like:
 
 ```kt
 // Your artifact
@@ -64,7 +64,6 @@ ReactNativeHostManager.initialize(application)
 As you can see the issue here is that now we are mixing the native App with react-native APIs, which is discouraged. If we stick to
 the above approach then the native App is free of interacting with react-native directly.
 
-
 ### Advanced Use Cases:
 
 If you built on top of the above approach, then you can rather easily scale it to incorporate advanced use cases. We will discuss here only one
@@ -130,4 +129,4 @@ fun sendEvent(event: String, handlerId: String) {
 fun sendEvent(event: String, handlerId: String) {
     eventHandlers[handlerId].invoke(event)
 }
-```
+```