Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Making RNTester publishable to NPM #12

Open
jevakallio opened this issue Jun 11, 2020 · 1 comment
Open

Making RNTester publishable to NPM #12

jevakallio opened this issue Jun 11, 2020 · 1 comment
Assignees

Comments

@jevakallio
Copy link

jevakallio commented Jun 11, 2020

Background

  • Lot of different companies are using RNTester as their internal test bench (Amazon, Microsoft)
  • They have to fork a copy for RN to use RNTester
  • RNTester builds are really slow because they require building full RN framework from source

Goal

  • Move RNTester to /packages forlder (yarn workspaces)
  • Publish RNTester to NPM
    • Have its own package.json and dependency tree, therefore it will be faster to build and iterate on
  • Not break anything
    • Finding all the places in RN repo (scripts, others...) that reference it
    • Document the change for people who use RNTester
    • As long as this doesn't get merged, everyone will be working off of this branch

Open questions

  • How will packaged RNTester consume the React Native source code?
    • Ask for input from RN FB core team
    • Proposed good options if we have ideas (@anku255)
@jevakallio
Copy link
Author

jevakallio commented Jun 15, 2020

Assumption is that we'll move forward by:

  • react-native init RNTester in /packages
  • Ensure it works and doesn't run into node package resolution or flow issues
  • yarn link in parent react-native and yarn link react-native in new RNTester
  • Make sure thing still works
  • Make small change to any RN component (e.g. Button) to ensure that changes are picked up across the yarn link symlink boundary
    • If it doesn't, let's discuss if live reload is a necessary feature, or what workarounds we might need

If above holds true, we should proceed my moving one screen from old RNTester to new at a time and ensuring all dependencies, tests etc. are correctly migrated.

Known issues:

  • Android Detox tests may not run correctly, ignore those for now. @anku255 and @manyaagarwal are working on it.

@rickhanlonii, can you let us know if there's anything wrong with above assumptions?

pull bot pushed a commit that referenced this issue Oct 16, 2020
Summary:
changelog: [internal]

Prevents 2 type converions:
1. int <-> size_t
2. int <-> int32_t

# Why is using size_t better when working with indexes.

## 1. Type conversion isn't for free.

Take this example

```
size_t calculate(int number) {
  return number + 1;
}
```

It generates following assembly (generated with armv8-a clang 10.0.0):

```
calculate(int):                          // calculate(int)
sub     sp, sp, #16                     // =16
str     w0, [sp, #12]
ldr     w8, [sp, #12]
add     w9, w8, #1                      // =1
mov     w8, w9
sxtw    x0, w8
add     sp, sp, #16                     // =16
ret
```

That's 9 instructions.

If we get rid of type conversion:

```
size_t calculate(size_t number) {
  return number + 1;
}
```

Assembly (generated with armv8-a clang 10.0.0):

```
calculate(unsigned long):                          // calculate(unsigned long)
sub     sp, sp, #16             // =16
str     x0, [sp, #8]
ldr     x8, [sp, #8]
add     x0, x8, #1              // =1
add     sp, sp, #16             // =16
ret
```

Compiler now produces only 7 instructions.

## Semantics

When using int for indexing, the type doesn't say much. By using `size_t`, just by looking at the type, it gives the reader more information about where it is coming from.

Reviewed By: JoshuaGross

Differential Revision: D24332248

fbshipit-source-id: 87ef982829ec14906ed9e002ea2e875fda4a0cd8
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants