-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Integrate the mobile React Native testsuite with the main Gutenberg build #9883
Conversation
The mobile code is assumed to be in the `gutenberg-mobile` subfolder.
The mobile project has its own lint rules and until the two projects can work off the same rules the main Gutenberg project needs to ignore it.
The mobile project still has Gutenberg as its own git submodule and so, many packages can be found in two places. Jest tests need to ignore the occurance of this second gutenberg sourcetree instance.
Instead, run `yarn install` earlier or in the same manner as `npm install`.
bin/install-node-nvm.sh
Outdated
@@ -72,6 +72,21 @@ npm install | |||
# Make sure npm is up-to-date | |||
npm install npm -g | |||
|
|||
# Check if yarn is installed | |||
if [ "$TRAVIS" != "true" ] && ! command_exists "yarn"; then |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Curious why yarn
is used for mobile? Can't we just make it "optional" and rely on npm consistently?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yarn is the main packager used in React Native apps, at least that's what FB is using in the documentation and all.
We wanted to stay close to whatever is most popular in the React Native ecosystem so we keep our dev setup as "best practices" as possible.
That said, I think there is probably no special reason to stay with yarn down the road so, I could see us replacing that later and certainly when we integrate the 2 toolchains (web, RN) even more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice addition, by looking at travis, it looks like the test are run in parallel and performant enought to include them.
I'd love some instructions on the testing documentation on how to run these locally... and how to potentially debug them if we notice failure.
For sure! I think I could add some instructions. To be honest, not sure where that testing documentation is so, any pointers will be appreciated :) That said, could we defer adding that documentation to a follow up PR? I can work on that PR immediately but, it would be awesome if we merged this one as soon as we can. It seems that even as we speak, changes land to Gutenberg that break the mobile (recent one: a Dropdown that breaks the mobile build #9687 ) and it would be useful to avoid that now that we have this PR and works. WDYT @youknowriad ? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 👍 but I'd appreciate a second opinion before moving forward.
FWIW, added fecffe2 to pick up Riad's good suggestion to add some documentation on how to use or debug in case of mobile error. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are some workflow issues here. I should expect to be able to run this without any issues, or at least very clear instructions on how to proceed (ideally with as few blockers as possible):
git clone https://github.com/WordPress/gutenberg.git
cd gutenberg
npm install
npm test
But there's a few issues:
- We don't present the Yarn requirement at any point except through
bin/install-node-nvm.sh
. I don't use this workflow, so I'd expect others won't as well. Thus, when run a user will see an errorsh: yarn: command not found
. - Even if the user manages to infer their way to installing Yarn, we don't automate the submodule initialization, so the user is then presented with
error Command "test:inside-gb" not found.
- ... I might have more commentary here, but even I couldn't figure out how I was supposed to get these tests actually running past this point. Running
git submodule --init --recursive
presents me with what appears to be an "invalid command" Git usage listing:
⇒ git submodule --init --recursive
usage: git submodule [--quiet] add [-b <branch>] [-f|--force] [--name <name>] [--reference <repository>] [--] <repository> [<path>]
or: git submodule [--quiet] status [--cached] [--recursive] [--] [<path>...]
or: git submodule [--quiet] init [--] [<path>...]
or: git submodule [--quiet] deinit [-f|--force] (--all| [--] <path>...)
or: git submodule [--quiet] update [--init] [--remote] [-N|--no-fetch] [-f|--force] [--checkout|--merge|--rebase] [--[no-]recommend-shallow] [--reference <repository>] [--recursive] [--] [<path>...]
or: git submodule [--quiet] summary [--cached|--files] [--summary-limit <n>] [commit] [--] [<path>...]
or: git submodule [--quiet] foreach [--recursive] <command>
or: git submodule [--quiet] sync [--recursive] [--] [<path>...]
or: git submodule [--quiet] absorbgitdirs [--] [<path>...]
Even if there's some intention around removing the Yarn dependency, we should then at least make this opt-in (only run by direct command and in Travis) until that's a reality.
docs/reference/testing-overview.md
Outdated
``` | ||
git submodule --init --recursive | ||
``` | ||
You can then use the available script to lanuch the mobile testsuite in isolation: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Typo: "lanuch" -> "launch"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed with 60a4935.
package.json
Outdated
@@ -181,10 +181,11 @@ | |||
"publish:check": "npm run build:packages && lerna updated", | |||
"publish:dev": "npm run build:packages && lerna publish --npm-tag next", | |||
"publish:prod": "npm run build:packages && lerna publish", | |||
"test": "npm run lint && npm run test-unit", | |||
"test": "npm run lint && npm run test-unit && npm run test-mobile", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can any of these be run concurrently
? I seem to recall some race conditions previously which prevented some concurrent testing, but if test-mobile
is meant to be isolated from other tests (at least for linting) maybe it's not problematic?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can't really atest for lint
and test-unit
between them but yeah, test-mobile
should be completely possible to run in parallel to the the rest.
Would you suggest I turn this into "test": "concurrently \"npm run lint && npm run test-unit\" \"npm run test-mobile\""
perhaps?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, that's what I'd have in mind.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done with 0c5da64.
package.json
Outdated
"pretest-e2e": "concurrently \"./bin/reset-e2e-tests.sh\" \"npm run build\"", | ||
"test-e2e": "cross-env JEST_PUPPETEER_CONFIG=test/e2e/puppeteer.config.js wp-scripts test-unit-js --config test/e2e/jest.config.json --runInBand", | ||
"test-e2e:watch": "npm run test-e2e -- --watch", | ||
"test-mobile": "cd gutenberg-mobile; yarn test:inside-gb; cd ..;", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have you checked that this works in Windows?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, no I haven't 😬
I'd be inclined to modify this into a single yarn --cwd gutenberg-mobile test:inside-gb
command if you think it can be problematic in its current form.
Thanks for adding your review @aduth ! I've addressed your inline comments and here's some response to your awesome review comments:
Aha, interesting. Not super familiar with the use cases of What I can try and do here though is install
Indeed, as mentioned in the PR description, one would need to do that manually. What I can do here is to hook the submodule update to the
Yeah, that's a 🤦♂️ error 😃. I forgot to add the
Gave it a quick try and it won't be trivial to remove the yarn dependency. So, for now, WDYT about adding it to EDIT: I went ahead and made |
* Yarn is installed locally as a development dependency * The mobile submodule is updated in preinstall * The mobile packages are installed in preinstall as well * Yarn is executed by providing the working (sub)directory as a parameter * No need to install yarn globally in Travis
Ready for another pass @aduth ! The "clone repo, npm install, npm test" routine should be available and running correctly, including the mobile tests. Let me know how that works for you, thanks! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It might be worth considering the size of Yarn as a dependency, but I'm content to prioritize the developer experience of the install. It didn't seem to bog down for me in any case.
Workflow feels much nicer now. Left one comment for your consideration.
@@ -25,5 +25,8 @@ | |||
"/test/e2e", | |||
"<rootDir>/.*/build/", | |||
"<rootDir>/.*/build-module/" | |||
], | |||
"modulePathIgnorePatterns": [ | |||
"<rootDir>/gutenberg-mobile/" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we include this for coveragePathIgnorePatterns
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, good point, seems like we should. Will look into it now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done with 24cd903.
Oh, I might not be well versed with this. Can you elaborate @aduth ? The In terms of how impactful can running it on every That said, if there is something more on your mind that is potentially a source of trouble please, do share so we pay attention.
Nice, good to hear! I'm sure we will keep an eye on keeping it good and better as we integrate more and more 👍 |
I wouldn't expect to be a concern for the runtime bundle, no. More in terms of cost as in the added time it takes to get a development environment up-and-running (the time of |
Thanks for the thorough reviews here all. Will go ahead and merge now, thanks! |
There's implied to be some follow-up tasks here. Where can I track their progress? Is the submodule intended to remain long-term? If not, which issue can I follow to track this progress? If so, how do we intend to remedy some of the workflow issues surrounding the submodule (showing as modified in local branch despite not being touched, "Find in Files" revealing duplicate copies from the submodule directory). |
👋 @aduth , I had added some documentation with fecffe2 earlier in this PR. See native-mobile-testing and debugging-native-mobile.
Not really. But you know how these things go... "short term" can be long :). Joke aside, the current setup kinda helps us move forward but it's far from optimal. I just wished I had some time to at least try the
None atm. Happy to accept suggestions on this one. What's the typical pattern we use in the Gutenberg repo to have such a ticket?
That's weird, how does that happen? Any steps available? FWIW, running the tests doesn't leave any trash behind to mark the submodule as dirty 🤔 . OTOH, changing to a different branch may leave the submodule un-updated, in which case
That should be relatively easy to fix. We just need to update all the nested (inside gutenberg-mobile) submodules except the gutenberg submodule, which is not needed in this setup. That should allieviate the duplicate results. |
It can also happen when running a |
Description
This PR adds the native mobile app repo as a git submodule and includes the mobile testsuite into the
npm test
script and the Travis test pipeline.How has this been tested?
Locally doing
npm test
runs green.To test:
cd
into itgit submodule update --init --recursive
to pull in the mobile submodule and its submodulesSetting RN platform to
string in your terminal's ouput.Types of changes
This PR doesn't introduce any code changes. All changes are done in the setup/tooling side of the project. In particular, the changes include:
yarn
, the package manager used by the mobile project. That's needed by the mobile npm scripts only..eslintignore
got adjusted and.stylelinignore
is introduced.test
npm script adopts thetest-mobile
script to run after the Gutenberg unit testsChecklist: