Hi there, thanks for checking out our repo!
Wingman serves as a practical reference for third-party developers integrating with the SEEK API, and complements the detailed documentation on our developer site. While third-party contributions are certainly welcome, this project is primarily driven by our internal priorities.
SEEKers: this repo is public, so don't commit or post anything that isn't ready for the entire world to see.
Wingman is documented through its README. We maintain changelogs and release notes on GitHub, and distribute underlying components as npm packages (wingman-fe).
Frontend components can be previewed through a Storybook. We plan to host the Wingman example stack publicly at some point (#3).
See the README design section for more details on the repository structure.
Submit an issue if you have a question, feature request or bug report.
If you work at SEEK, #indirect is your friend.
Feel free to create a pull request for trivial fixes and improvements.
For more substantial features, please submit an issue first. This lets us evaluate whether the feature fits the direction of the project and discuss possible approaches.
We depend on upstream tooling like sku that are predominantly tested on macOS and Linux. If you're on Windows, we recommend the Windows Subsystem for Linux.
First, some JavaScript tooling:
- Node.js LTS
- pnpm as per
package.json#packageManager
Next, install npm dependencies:
pnpm installWe use GitHub flow.
Create a new branch off of the latest commit on main:
git fetch origin
git switch --create your-branch-name origin/mainDevelop, test and commit your changes on this branch. (Make sure to include the appropriate changeset.)
git add --all
git commitFinally, push your branch to GitHub and create a pull request:
git push --set-upstream origin your-branch-nameIf you don't have push access, you may need to fork the repo and push there instead:
git remote add fork [email protected]:your-username/wingman.git
git push --set-upstream fork your-branch-nameA maintainer will get to your pull request and review the changes. If all is well, they will merge your pull request into main.
You may find it easier to develop alongside unit tests:
pnpm fe test --watchFormat your code once you're happy with it:
pnpm formatWe run linting and testing in CI, but consider running these commands locally for a faster feedback loop:
pnpm lint
pnpm testStart local development servers:
pnpm fe startWe use Changesets to manage package releases. You'll see a 🦋 bot gliding around pull requests.
You should write a changeset if you are changing the public Wingman interface, which includes:
- Package code under fe/lib
- npm dependencies
On the other hand, a changeset is not necessary for:
- Documentation like the README
- Example code under fe/example
- Internal refactoring that preserves the existing interface
- npm dev dependencies
pnpm changesetThe Changesets CLI is interactive and follows semantic versioning:
- Patch release
0.0.X: fixes or tweaks to existing functionality - Minor release
0.X.0: new, backwards-compatible functionality - Major release
X.0.0: backwards-incompatible modification
The Changesets CLI will generate a Markdown file under .changeset, which you should include in your pull request. It doesn't need to be part of the same commit as the rest of your changes. Feel free to manually edit this file to include more details about your change.
When a pull request with a changeset is merged,
our CI workflow will create a new Version Packages PR.
The changesets are used to infer the next semantic version and to update the changelogs.
This PR may be left open to collate multiple changes into the next version. A maintainer will merge it once ready, and our release GitHub Actions workflow will publish the associated GitHub release and npm package version.
Prereleases can be created on demand via seek-oss/changesets-snapshot.
Manually run the Snapshot workflow for the main branch in GitHub Actions to publish a new snapshot version to npm.