Wrangling Python in a Typescript Monorepo: Weighing the Pros and Cons


# Introduction

In the realm of TypeScript-based web applications, I've had the privilege of working on a few distinct projects with diferent teams, both for work and for personal projects. Interestingly, three of these endeavors organically evolved into eventually needing a Python microservice component, primarily due to user requirements and evolving tech landscapes.

In all of these projects, each of the teams I worked with made a conscious decision to incorporate these Python services within a monorepo as opposed to keeping the Python package in a separate repository. This has been a decision that has since proven to be exceptionally beneficial across the projects, but not without its own challenges. 

In this series of blogs, I'll be documenting my process and thoughts as I experiment with the use of different monorepo tools to integrate Python in my TypeScript-based monorepository, in hopes that it'll help other developers who are exploring a similar use case as well!

# A Three-part Series

This blog is broken down into three parts: 
1. Wrangling Python in a Typescript Monorepo: Weighing the Pros and Cons
2. Wrangling Python in a Typescript Monorepo: Nx with Python Tutorial
3. Wrangling Python in a Typescript Monorepo: Turbo with Python Tutorial

The first part, **'Weighing the Pros and Cons'**, will provide an overview with my own personal anecdotes of the pros and cons of investing effort to integrate a Python package into a TypeScript-based monorepo. I will also talk about the two monorepo tools I have used, Nx and Turbo, and talk about my recommendations on which to use for various contexts.

The second part, **'Nx with Python Tutorial'**, will be a detailed tutorial on how to use the monorepo tool, Nx, to integrate Python in a TypeScript-based monorepo.

The third part, **'Turbo with Python Tutorial'**, will be a detailed tutorial on how to use the monorepo tool, Turbo, to integrate Python in a TypeScript-based monorepo.

**TO BE CONTINUED**





A Beginner's Guide to GitHub Contribution Workflow


Are you interested in contributing to open-source projects on GitHub? This guide will walk you through a basic workflow for making contributions while following standard software development practices. By adopting this [trunk-based development workflow](https://www.atlassian.com/continuous-delivery/continuous-integration/trunk-based-development), you can merge small, frequent updates to a project's main branch, enabling faster deployments and facilitating effective collaboration among developers.

## Step 1: Write a GitHub Issue
To kick off the workflow, start by creating a new issue on the GitHub repository for the project. Issues can encompass various tasks like bug fixes, feature requests, documentation updates, and general chores. Here's how you can do it:

1. Go to your GitHub repository's issues page.
2. Follow [GitHub's documentation](https://docs.github.com/en/issues/tracking-your-work-with-issues/creating-an-issue) to create a new issue.
3. Use the provided issue template (if available), filling out relevant sections and deleting any irrelevant ones. Be as detailed as possible, ensuring anyone who reads the issue knows exactly what needs to be done. Consider adding screenshots, especially for bug reports, and provide a step-by-step reproduction guide for bugs.
4. Fill in the form fields on the right panel.
5. [Assign the issue to a specific team member](https://docs.github.com/en/issues/tracking-your-work-with-issues/assigning-issues-and-pull-requests-to-other-github-users) or yourself to avoid duplication.
6. [Add the project](https://docs.github.com/en/issues/organizing-your-work-with-project-boards/tracking-work-with-project-boards/adding-issues-and-pull-requests-to-a-project-board#adding-issues-and-pull-requests-to-a-project-board-from-the-sidebar) to your repository's project board.
7. [Associate the issue](https://docs.github.com/en/issues/using-labels-and-milestones-to-track-work/associating-milestones-with-issues-and-pull-requests) with a relevant milestone or create a new one if needed.
8. [Assign a label](https://docs.github.com/en/issues/using-labels-and-milestones-to-track-work/managing-labels) that best describes the issue.
9. Create the issue and verify that it appears on the issues page.

## Step 2: Choose an Issue to Work On
If you don't have a new issue to add or have already added one, you can browse the issues page to select an issue you'd like to contribute to. Follow these steps:

1. [Assign the issue](https://docs.github.com/en/issues/tracking-your-work-with-issues/assigning-issues-and-pull-requests-to-other-github-users) to yourself in the "Assignee" tab.
2. Mark the status as "In Progress" in the "Project" section on the right-hand panel.

## Step 3: Create a New Branch for the Issue
Before you start working on an issue, create a new branch specifically for that task. Follow these instructions:

1. On the issue page, refer to [GitHub's documentation](https://docs.github.com/en/issues/tracking-your-work-with-issues/creating-a-branch-for-an-issue) on creating a branch.
2. Modify the default generated branch name by removing the issue number and adding a prefix using the issue label, separated by a '/' symbol. For example, if the issue is labeled as "feat" and relates to changing the header name on a website, the branch could be named "feat/change-header-name-on-website". You can shorten the issue title if it's excessively long, as long as you include the prefix label and separator, which is important for organizing branches with certain Git version control tools.
3. Choose whether to check out the branch locally or use [GitHub Desktop](https://desktop.github.com/) (recommended for new developers):
  - To check out locally, a pop-up modal will appear after clicking "Create," providing you with instructions such as running `git fetch origin` and `git checkout feat/your-new-branch`. Follow these commands in your terminal, which should be located in the project directory of the repository clone.
  - If using [GitHub Desktop](https://desktop.github.com/), click the option to open the branch in Visual Studio Code, and it will automatically navigate you to the new branch.

## Step 4: Make Your Contribution
Once you're in the new branch, you can start making code changes. All modifications you make will be confined to your local computer until you're ready to commit and push them to the remote repository on GitHub. This allows you to safely work on changes without affecting other code branches until you're confident in merging them.

## Step 5: Adding Your Changes with Git Add
Once you are ready to add your changes to the Git staging area, you can use the git add command. If you want to add specific files, you can run `git add <filename>`. To add all the changes you have made so far, you can use `git add .`. You can find more detailed documentation on adding changes [here](https://github.com/git-guides/git-add).

## Step 6: Committing your Changes with git commit
When you are ready to create a new commit with the changes you have added, you can use the `git commit` command. It is generally recommended to make small, focused commits to facilitate easier rollback to previous versions. Additionally, multiple small commits can be combined into a larger commit when there is no need for a rollback.

For a commit, use the following command:
```bash
git commit -m "<your commit message>" -m "<your commit description>"
```
The commit message should start with the issue label, followed by the topic in parentheses, and separated from the main commit message with a colon. For example, a commit related to a feature that changes the website header in the web app package could have a commit message like: `"feat(web): Changed header in website"`. Keep the commit message concise, and provide additional details in the description.

You can include further details in the description and [reference the issue that the changes will close](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue). For example, if the change is intended to close issue #27 and you want to provide more details, you can add the following in the description: "Changed header title from 'Hello' to 'Hello World.' Closes #27." To split the description into multiple lines, use another -m option for each line.

Here is an example of a Git commit command:
```bash
git commit -m "feat(web): Changed header in website" -m "Changed header title from 'Hello' to 'Hello World.' Closes #27."
```
Alternatively, if you prefer separate lines for clarity:
```bash
git commit -m "feat(web): Changed header in website" -m "Changed header title from 'Hello' to 'Hello World.'" -m "Closes #27."
```

You can create as many commits as you need using the `git add` and `git commit` workflow. Feel free to read more on these workflows [here](https://github.com/git-guides/git-commit)!

## Step 7: Pushing your Commits to Github with `git push`
Once you are satisfied with your commits and want to push them to the remote repository on GitHub, use the command `git push`. Assuming that your local branch has the same commits as the remote branch and you haven't used commands like `git commit --amend` or `git rebase`, you can proceed with git push. You can refer to the more [comprehensive documentation on the git push process](https://github.com/git-guides/git-push).

## Step 8: Opening a Pull Request
After pushing your changes to the remote repository, it's time to open a pull request (PR) for other developers to review your code. Follow the instructions provided in [GitHub's documentation](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request) to begin the process.

It helps to keep the following in mind for the PR description:
1. Provide a detailed description of the changes to provide context for the reviewer.
2. Reference the issue number.
3. Give step-by-step instructions for the reviewer to test your code.
4. Include screenshots demonstrating the expected behavior.

You can also [request specific individuals](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/requesting-a-pull-request-review) to review your code to notify them!

Once your PR is open, you may now wait for other developers to review it.

## Step 9: Reviewing a PR
As a reviewer, you can choose any open pull request to review. Follow [this guide](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/about-pull-request-reviews) for reviewing PRs. It is recommended to use either "Request Changes" or "Approved" as the review status to give the developer specific feedback on what to do.

## Step 10: Making Changes Requested by a Reviewer
If your PR has been marked for changes by a reviewer, you can make the necessary modifications by following these steps:

1. Checkout your branch on your local computer.
2. Make your changes.
3. Add the changes.
4. Commit the changes.
5. Push the commit.
6. Request the same reviewer to check your changes and approve them.

## Step 11: Merging a PR
To merge a PR on behalf of a developer, ensure the following conditions are met:

1. There are no pending change requests from other reviewers. If there are, check with the other reviewer or developer to see if the issues have been resolved.
2. You have approved the PR.
3. There are no merge conflicts. The merge button should be all green without warnings. If there are merge conflicts, leave the PR as a change request and ask the developer to [rebase their branch](https://www.atlassian.com/git/tutorials/rewriting-history/git-rebase#:~:text=What%20is%20git%20rebase%3F&text=From%20a%20content%20perspective%2C%20rebasing,them%20to%20the%20specified%20base.) onto dev to resolve the conflicts.

If the conditions are met, you can follow the instructions provided in [GitHub's documentation to merge the PR](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/merging-a-pull-request).

## Additional Git Commands to Become a Git God
Here are some additional Git commands that can enhance your workflow:

- [`git rebase <another branch>`](https://www.atlassian.com/git/tutorials/rewriting-history/git-rebase#:~:text=What%20is%20git%20rebase%3F&text=From%20a%20content%20perspective%2C%20rebasing,them%20to%20the%20specified%20base.): Reset the head of your current branch to the new head of another branch. This is typically used to rebase onto the `dev` branch when there are new updates on `dev`.
- [`git rebase --interactive`](https://www.atlassian.com/git/tutorials/rewriting-history/git-rebase#:~:text=What%20is%20git%20rebase%3F&text=From%20a%20content%20perspective%2C%20rebasing,them%20to%20the%20specified%20base.): Interactively choose what to do with each commit in your commit history.
- [`git commit --amend`](https://docs.github.com/en/pull-requests/committing-changes-to-your-project/creating-and-editing-commits/changing-a-commit-message): Add new changes to your most recent commit or change the commit message.
- [`git reset --hard <another branch>`](https://initialcommit.com/blog/git-reset#:~:text=38e2a6e%20Initial%20commit-,What%20is%20the%20use%20of%20git%20reset%20%2D%2Dhard%3F,state%20of%20the%20specified%20commit.): Reset your branch to match another branch. This is usually used to reset the local branch to the remote branch when you want to revert to the remote repository's state.
- [`git push --force`](https://www.git-tower.com/learn/git/faq/git-force-push): Force push, overwriting whatever is on the remote repository, regardless of any differences in commit histories.

## Additional Tools to Complement Git
Here are some additional tools that can complement your Git workflow:
- [Resolving Merge Conflicts](https://linuxpip.org/fix-merge-conflicts-vscode/): Resolving merge conflicts is a crucial skill. You should learn how to do it. This is often required when performing `git rebase dev` as conflicting file changes may require manual resolution.
- [Using a Text Editor to Amend Commit Messages](https://stackoverflow.com/questions/48208487/how-to-add-commit-message-using-vim): When the `git commit --amend` command is run, this will spin up a text editor to edit your commit message. By default, this is usually Vim. You can either learn to love it, or just [change the text editor](https://docs.github.com/en/get-started/getting-started-with-git/associating-text-editors-with-git) to something else.
- [Git Graph](https://marketplace.visualstudio.com/items?itemName=mhutchie.git-graph): This VSCode extension visualizes your entire git history and provides a GUI for running commands like git rebase. It is very useful for understanding and managing your Git workflow.
- [Github Desktop](https://desktop.github.com/): This tool is highly recommended for beginners and intermediate Git users. It offers an intuitive interface and seamless integration with GitHub, simplifying the Git process.
- [Fork](https://git-fork.com/): Fork is an advanced Git client/GUI that provides more features than GitHub Desktop. It is suitable for users looking for a more comprehensive Git tool.


Showwcase Hackfest 2023


I am so thrilled to be involved in Showwcase Hackathon 2023 as a mentor! For this year's hackathon, Showwcase will be making their APIs public for all interested developers to leverage on all the incredible features they have developed for their mission of creating an inclusive community for professionals in software development.

# Showwcase Hackfest 2023

[Register Here](https://www.showwcase.com/hackathon/hackfest)

I am so thrilled to be involved in Showwcase Hackathon 2023 as a mentor! For this year's hackathon, Showwcase will be making their APIs public for all interested developers to leverage on all the incredible features they have developed for their mission of creating an inclusive community for professionals in software development.

Do you want to create a live vizualization of the most common technologies used by developers? You can use Showwcase's get user tech stack API for that!

Or do you perhaps want to create a job alert function to find job offers similar to a prior job's skillset to help those in the community affected by tech layoffs? You can use Showwcase's get active offers API to get new and active job offers for that!

There's so many things you can do with Showwcase's vast API services, and I encourage you to try it out through their Hackathon! Who knows, you might even walk away with prizes up to $5000, or get a cool swag bag delivered straight from Showwcase's office in San Francisco!

If you have any further questions about the Hackathon, feel free to reach out to me, or even better, to [Tapas Adhikary](https://www.linkedin.com/in/tapasadhikary/), Showwcase's amazing Head of Content! 💫💫💫

# Hackfest Description

Have you ever had an idea you’re excited about, that you know developers would just die to use, build it and turn it into something useful for 100,000 other developers?

Well, let’s go. We’re flipping the switch and making our APIs public! That’s right. Developers like you can now dive into the Showwcase API playground and create awesome apps that will be used by over 100,000 developers on Showwcase!

Want to build a note taking app? AI profile image generators? Voice based Thread posting? You are only limited by your imagination. LFGGGG!!

We’re hosting an epic hackathon to bring out the best minds in the developer community and spur innovation for the future. And guess what? You’ll win prizes for your brilliant creations! 💰 So, get your coding hats on, join the fun, and let’s build the future together on the network built for developers! #BuiltOnShowwcase


Wrangling Python in a Typescript Monorepo: Weighing the Pros and Cons

Introduction

Tech Blog (Pending Update)