Forem: CodeNameGrant

Domain-First Nx Monorepos: Using `packages/` to Make Ownership and Boundaries Obvious

CodeNameGrant — Mon, 23 Feb 2026 11:31:51 +0000

Where should this go? Which apps are using this library?

Those two questions are plaguing my team as our monorepo grows. Not because we don’t know Nx, TypeScript, or React—but because our folder structure doesn’t clearly communicate ownership.

We started with a pretty standard setup:

apps/<app>
libs/<domain>/<lib>
libs/shared/<lib>

That structure was a great starting point (this was our first real dive into monorepo architecture). It was simple, it scaled enough, and it let us move fast early on. But we’re now at ~40 libraries and growing, and it’s becoming less obvious:

where a new library should live, and
whether a library is truly domain-specific or actually shared.

This post explains why we plan to migrate to a domain-first packages/ layout. The main goal being domain clarity (and making module boundaries easier to enforce consistently).

Flat `libs/` worked… until it didn’t

The hardest part of a growing monorepo isn’t the tooling—it’s the ambiguity. When everything lives side-by-side in libs/, the folder structure stops answering basic questions, like:

Who owns this library?
Which app is it actually supporting?
Is this genuinely shared, or did someone just reuse it once?
If I’m adding a new thing, where’s the “obvious” place to put it?

So instead of the repo guiding you, you end up relying on tribal knowledge (or you run nx graph and play detective).

A concrete example (the kind that trips new people up)

We have a contract-web app and a library with a name that sounds like it belongs to it—something like data-access-contract. If you’re new to the workspace, you’d make a totally reasonable assumption:

“Cool, contract-web uses data-access-contract.”

Except… it doesn’t. company-web is the one consuming it.

Nothing about a flat folder structure makes that mismatch obvious. And this is where the time goes. Not in builds—mostly in the little moments:

onboarding takes longer than it should,
“where should this live?” becomes a recurring message thread,
libraries slowly drift into whatever location was convenient at the time,
and cross-domain dependencies happen by accident.

At this point, our bottleneck isn’t build speed—it’s how quickly someone can answer: “Where does this code belong?”

Implementing `packages/`: make the repo explain itself

What we want is simple: we want the repo structure to answer the questions we keep asking.

What domain does this code belong to?
Is it shared, or is it local to one app?
Where does a new feature go?
If I’m trying to understand a domain, where do I start?

That’s what’s driving the move to a domain-first layout:

packages/<domain>/app/...
packages/<domain>/libs/...
packages/shared/libs/...

Why `packages/`?

“Packages” isn’t a new monorepo law; it’s just a common convention that communicates:

“These are grouped things that belong together under a single workspace.”

Nx supports many layouts. We’re choosing this one because it makes domain boundaries visible, which reduces cognitive load.

Module boundaries: make the “right” thing the easy thing

We’re also using this restructure to make module boundaries easier to reason about and enforce. Nx boundaries are tag-based, so the plan is:

tag everything in a domain with domain:<domain>
tag shared libs with domain:shared

Then enforce a few simple rules:

A domain app can import:
- libraries from its own domain, and
- libraries from domain:shared
Domain libraries should not import from other domains
shared libraries should not import from domain libraries

The real win here isn’t the lint rule itself—we can write those today. The win is that once the code is physically grouped by domain, those rules stop feeling like “extra process” and start feeling like the natural shape of the repo.

In other words: developers don’t need deep context to do the right thing, and when someone does the wrong thing, Nx catches it early.

High-level migration plan (draft)

Use the @nx/workspace:move generator to do the heavy lifting when moving projects in an Nx Workspace

[ ] Create the new /packages skeleton (/packages/<domain> and /packages/shared)
[ ] Move each app one at a time from apps/<app> → packages/<domain>/app
- [ ] Tag each project with domain:<domain>
- [ ] Verify it’s visible in nx graph
[ ] Move the libs that are already shared from libs/shared/* → packages/shared/libs/*
- [ ] Tag each project with domain:shared
- [ ] Rename projects only when it’s an easy win during the move (otherwise leave names alone for now)
[ ] Move “definitely domain-local” libs (one domain at a time)
- [ ] For a given domain, move only the libs we’re confident are not shared
- [ ] Tag each project with domain:<domain>
[ ] Handle the “maybe shared” libs (after the obvious stuff is moved)
- [ ] For each “maybe shared” lib: keep it domain-local or intentionally promote it to shared
- [ ] Tag each project appropriately
[ ] Clean-up pass: rename projects that still need it
- [ ] Standardize remaining project names to match the new conventions

If this works the way we expect, the best sign will be that people stop asking where things should go—because the answer will be obvious.

Bonus benefits

None of this is guaranteed for every Nx monorepo. These benefits are mostly a product of how our repo works today. We also may not implement all of these immediately—think of them as “now possible / now easier” rather than promised outcomes.

1) Simpler GraphQL Code Generator workflow

In our environment, GraphQL codegen is currently very flexible (flags for different services and libs), but that flexibility comes with cognitive overhead and occasional noisy regen. With packages/<domain>/*, we can shift the default workflow to: “I’m working on this app → run codegen for this app/domain”, and have it target:

packages/<domain>/libs/*, plus
packages/shared/libs/*

That trades some granularity for a workflow that’s harder to mess up.

2) Apollo type policies become easier to wire consistently

Right now, type policies live in feature libs and apps manually import them. That’s workable, but easy to forget as features move or get reused. Once the repo is domain-grouped, it becomes straightforward to generate an app-level “policy aggregator” (per domain app) that automatically pulls in:

domain policies exported from all domain-local libs, plus
shared policies

This won’t magically solve all policy design problems, but it reduces the “remember to wire it up in every app” overhead.

3) Generators become much more predictable (domain + type = obvious destination)

With a flat libs/ directory, a generator can create a library, but it can’t reliably answer: which app/domain should this belong to? That decision often depends on local context.

After the migration, we can write (or customize) generators that take inputs like:

domain (company, contract, etc.)
type (feature, ui, data-access, …)
name (invoices, teams, …) …and always place the output in a predictable location, e.g.:
packages/company/libs/feature-invoices

This is one of those quality-of-life improvements that compounds over time.

4) Possible future win: more predictable implicit libraries

This one is more of an idea than a guaranteed outcome, but a domain-first folder structure should make Nx’s “implicit libraries” approach a lot more predictable, because the filesystem starts encoding intent (domain + shared) instead of everything living in one flat space.

If we go down this route later, the hope is we can model impacts with fewer manual touch points—similar to the approach described here: Nx Implicit Libraries: The Hidden Gem

Closing

Ultimately, we want a monorepo that’s easy to navigate, hard to misuse, and doesn’t require tribal knowledge to be productive.

Flip Your CI Like a Switch: Instantly Toggle Flags with GitHub Actions Variables

CodeNameGrant — Thu, 16 Oct 2025 07:48:27 +0000

Ever wish you could tweak your CI pipeline on the fly—change logging levels, skip caching, or toggle features—without touching a single line of code or YAML?

With GitHub Actions variables, you can.

What Are GitHub Actions Variables?

Like GitHub Secrets (secrets), Variables (vars) are simple key-value pairs you define in your repository.

You can use them to control workflow behavior without committing changes, making them perfect for feature flags, build tweaks, or environment switches.

Example: Controlling Nx Build Flags

Imagine you want to control verbose logging and cache usage for an nx build command.

In your repo settings under Secrets and Variables → Actions → Variables (tab) define the following:

NX_VERBOSE_MODE: true or false
NX_USE_NX_CACHE: true or false

Then use them directly in your workflow:

- name: Build
  shell: bash
  run: >
    npx nx build app-name
    ${{ vars.NX_VERBOSE_MODE == 'true' && '--verbose' || '' }}
    ${{ vars.NX_USE_NX_CACHE != 'true' && '--skip-nx-cache' || '' }}

Using run: > (folded style) combines all lines into a single line, replacing line breaks with a space. Its great in this use-case making the command easy to read.

Now you can toggle flags directly from the Variables tab—no pull requests, no commits, just instant control.

Monorepos: A Year in Review

CodeNameGrant — Thu, 04 Sep 2025 20:41:44 +0000

One Repository to Rule Them All

Its been a year since we started migrating our suite of web applications into a monorepo workspace and I thought it was time share some wins and warts and how we made it all happen.

The goal? To simplify dependency management, reduce code duplication, and make expanding the suite to include more apps or feature libraries easier.

Our team is not the smallest team, but it is the next smallest. With only a two-person development team, every decision mattered—from the scope of the migration project to the order that apps would be moved and how to structure shared libraries. However a small team comes with it the advantage of being able to make rapid decisions without lengthy debates, maintain a high visibility of changes, and experiment with implementation options without affecting a large group of stakeholders.

So lets Jump in, I'm excited to share the results!

Our Approach

A major requirement during the migration was that we couldn’t pause new feature development or bug fixes on existing apps. So we chose to follow an incremental approach: migrating one full app at a time (and all its parts). We started with a smaller app, so we could also focus on setting up the workspace, pipelines, and tooling before scaling to the other applications.

To keep things manageable, we included a caveat, "the app being migrated wouldn’t have new feature development scheduled". Minor patches and bug fixes were fine, but juggling ongoing updates while also migrating those updates risked doubling work and introducing confusion.

The Tech Stack: Nx & Nx Cloud

Of all the monorepo tools, we decided Nx and Nx Cloud were the best fit for us. Its CLI is well-documented, with plenty of examples and tutorials, which made it feel less daunting to learn. This was important—if we couldn’t figure out how to use it effectively, not only would our migration stall, but stakeholders might start doubting whether moving to a monorepo was even a good idea. Nx also comes with plugins for our existing tech stack and Nx Cloud let us experiment extensively before starting the migration with a generous free tier.

Stories from the Journey

Along the way, a few memorable challenges and discoveries taught us more than any checklist ever could.

The Dayjs vs. Kendo Formatting Headache
We ran into a sneaky bug when our dayjs formatter clashed with KendoReact. Day.js uses ISO formatting (eg. YYYY for a 4-digit year), while KendoReact expects its own notation (ie. yyyy). The fix was to use Day.js to handle all calculations and comparisons, and leave all the formatting to KendoReact, keeping everything consistent.

Rolling Our Own Keycloak Wrapper
The React Keycloak wrapper we originally used was outdated and barely maintained. With no other alternatives, we built our own, learning token flows, refresh cycles, and how React talks to Keycloak. The result: a reliable, battle-tested wrapper and a team that actually understands how authentication works.

The Refactor That Ate the Repo
Refactoring a set of shared UI components started ith teh best of intentions, and suddenly the refactor had touched 150+ files. Nope! The PR was far too big to review safely, so we had to reverted it. Instead, we tackled updates piecemeal with smaller, focused PRs—easier reviews, less risk, and more confidence. Lesson learned: big-bang changes feel efficient, but controlled iteration wins.

The Documentation We Didn’t Know We Needed
We’d never focused much on documentation—who does, knowledge lived in our heads mostly. But when we invited an external team to review our Nx workspace, we had to actually write things down. At first, it felt like busywork, but it clarified our reasoning, exposed gaps, and suddenly onboarding a new dev didn’t seem impossible. What started as “just for the reviewer” ended up being for us: documentation became a tool for thinking.

Code That Could Stay Put

Not everything needs to be migrated. A useful lens is to ask: Is it valuable, used often, and under our control? If not, it might be better left alone.

Short-lived or legacy code — End-of-life systems, POCs, and prototypes are rarely worth the effort.
Low-impact tools — Admin dashboards, internal scripts, or utilities used by a handful of people could be evaluated case-by-case and categorised as low-priority to be done after the main goals have been achieved.
Stable or performance-critical modules — For code that’s rock-solid or finely tuned for performance, don’t prioritize moving it just for the sake of uniformity. Wait until change is truly needed.
Archived or compliance projects — Kept only for historical or legal reasons, these don’t need to me moved.

Side Effects We Actually Liked

On top of the main goals, there were a few extra benefits made the year even sweeter…

Zero version drama – Honestly, we hadn't thought about keeping the workspace up to date during the migration, but even before all apps were fully migrated, we were running workspace-wide updates between app migrations. By using nx migrate, Nx auto-updated all its dependencies for us. Genuis!
Smoother developer experience – With shared libraries, single source of truth, and consolidated utilities, knowledge sharing became easier. Tracking components or utilities was simpler, and both local development and onboarding became more predictable.
Reviews that matter – Shared modules are tested rigorously, so we no longer need to review every utility implementation. Code reviews focus on feature logic instead of rehashing the same patterns, a big improvement over the old polyrepo setup.
Team Trust in Action - Full disclosure: at first we didn't have default branch protection policies in place, not because we wanted to avoid code-reviews, we just couldn't get the GitHub rules sets to behave the way we wanted. We still practiced code reviews, they just weren't enforced. It’s not perfect, but it worked for our small, trusting team—and it shows there’s room to grow.

Lessons Learned

A year into our monorepo migration, a few key lessons stand out—lessons that helped us keep the project moving while learning along the way.

1. Start Smart
Before touching production, we spun up many test workspaces and pipelines. Experimenting early gave us confidence and reduced “gotchas.” At the same time, establishing clear boundaries—deciding which apps or modules to migrate and what fell in our mandate—kept the work manageable. Nx generators like @nx/workspace:move made it easy to adjust structure later, so we didn’t need to get everything perfect from day one.

2. Move in Steps
Migrating one app at a time allowed us to validate our setup and refine tooling before tackling bigger projects. Each app became a learning opportunity rather than a risk. We also learned to accept that first-pass solutions wouldn’t cover every edge case. Some duplication or temporary shortcuts were inevitable, but planning to refine incrementally kept momentum going without compromising quality.

3. Keep It Practical
It’s tempting to overengineer: abstract everything, customize every build, and aim for perfection. In reality, sticking to practical choices—leaning on defaults, balancing abstraction, and making deliberate trade-offs—kept progress moving. Sometimes duplicating a component temporarily was faster, with the intent to refactor later once all use cases were understood. Pragmatic decisions lead to reusable code without slowing development.

4. Document as You Go
Writing down assumptions, documenting shared components, utilities, and conventions clarified our thinking and improved onboarding. Initially, it felt like busywork for an external reviewer, but it quickly became an internal tool for tracking decisions, spotting gaps, and making the migration more maintainable. Good documentation isn’t just for others—it reinforces clarity for your own team.

5. Clean as You Go
Unexpected quirks, outdated dependencies, and long-forgotten scripts surfaced repeatedly. Each one became an opportunity to clean up and standardize. Tackling these early prevented bigger problems down the line and improved overall code quality.

6. Build Confidence
Rigorous testing in shared modules turned out to be a huge time-saver. With solid test coverage, we no longer needed to review every utility implementation, and refactoring or updating apps felt safer. Testing wasn’t just about catching bugs—it reinforced trust in the shared code and the migration as a whole.

Taken together, these lessons show that a thoughtful, incremental approach—prioritizing practicality, documentation, and testing—makes a monorepo migration manageable, educational, and ultimately rewarding.

Conclusion

One year in, the monorepo has delivered more than just technical improvements—it has transformed how we work. Getting here wasn’t simple. Each app migration involved careful planning, rethinking abstractions, and multiple iterations as new requirements and edge cases emerged. There were moments of trial and error, but every challenge taught us something valuable.

Today, apps are consistent, upgrades are simpler, and bootstrapping new applications is faster thanks to shared layouts, utilities, and workflows. CI/CD automation still has room to grow, onboarding could be smoother, and shared libraries will keep evolving—but the foundation is solid, and day-to-day development is now more predictable and less error-prone.

For small teams, the lessons are clear: embrace an incremental migration, prioritize practical reuse over perfection, and experiment and leverage tools like Nx to make things easier for you. The monorepo isn’t just a technical shift—it’s a cultural one, and the effort has been well worth it.

One repo, many lessons, endless possibilities.

Supercharging Your Workflows with Local GitHub Actions

CodeNameGrant — Fri, 29 Aug 2025 19:01:52 +0000

If you’ve worked with GitHub Actions before, you’ve probably pulled in a bunch of ready-made steps from the Marketplace. That’s awesome for common needs like setting up Node, caching dependencies, or deploying to cloud providers.

But what about those repetitive, project-specific steps that aren’t worth publishing to the whole world? That’s where local GitHub Actions shine.

What Are Local Actions?

A local action is a custom GitHub Action that lives inside your own repository. Unlike Marketplace Actions, they’re not shared publicly—just tailored helpers your workflows can use again and again.

They live under the special .github/actions/ directory in your repo:

.github/   
  actions/
    bootstrap-node/
      README.md (optional)
      action.yml

From here, you can call them in any workflow as if they were published actions.

Demo: Bootstrap Node Environment

Let’s say multiple workflows in your project need the same basic setup:

Setup Node.js
Run npm ci

Instead of repeating that block everywhere (and making sure they all use Node v20 and cache npm correctly), you create a local action:

`.github/actions/bootstrap-node/action.yml`

name: 'Bootstrap Node Environment'
description: 'Sets up Node.js (version 20) and optionally installs npm dependencies'

inputs:
  installDeps:
    description: 'Whether to install npm dependencies'
    required: false
    default: 'true'

runs:
  using: 'composite'

  steps:
    - name: Setup Node.js
      uses: actions/setup-node@v4
      with:
        node-version: 20
        cache: 'npm'

    - name: Install dependencies
      if: ${{ inputs.installDeps == 'true' }}
      shell: bash
      run: npm ci

Usage in a workflow

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: ./.github/actions/bootstrap-node

      # Node environemnt is ready to use

Now every workflow that needs a Node environment can use this clean one-liner instead of duplicating setup code.

Exciting Use Cases for Local GitHub Actions

Local actions are great for project-specific tasks that you’d otherwise duplicate across multiple workflows. Some examples:

Monorepo Dependency Filtering – Only run jobs for apps/libs that actually changed.
Reusable Security Checks – Centralize audits (npm, yarn, trivy) into one action.
Automated Changelog Generation – Auto-generate and update CHANGELOG.md from commits.
Slack/Teams Notifications – Send consistent, branded build/deploy alerts.
Custom Preview Environments – Spin up ephemeral environments (e.g., Vercel/Netlify/containers) for each PR.
Standardized Code Quality Gates – Bundle linting, formatting, and type-checks into one action for consistency across workflows.

Here is a small (for now) local-action-toolbox, that has some demos.

Why Use Local Actions?

✅ DRY (Don’t Repeat Yourself): No more copy-pasting steps.
✅ Clarity: Workflows are more streamlined and readable.
✅ Flexibility: Inputs let you toggle behavior (like installDeps: false).

Wrap-Up

Local GitHub Actions are a small investment that can pay off in a big way. They help keep workflows clean, reduce copy-paste drift, and turn repetitive steps into simple, reusable building blocks.

So the next time you spot the same steps repeated across multiple workflows, think about wrapping them into a local action. It’s one of those moves your future self—and your teammates—will definitely appreciate.

Link Pull Requests to JIRA Issues with Ease

CodeNameGrant — Thu, 28 Aug 2025 18:18:30 +0000

Linking GitHub pull requests to JIRA tickets can be irritating. PR descriptions often miss references to the right ticket, or contributors forget to include links altogether. This makes it harder for reviewers and project managers to connect code changes to the actual work item.

The JIRA PR Link Action can solve that problem.

🔗 What It Does

This GitHub Action automatically adds a “Link to JIRA ticket” line to your pull request description whenever it finds a valid JIRA key in the PR title.

No more manual setting up Markdown links, as long as you include the ticket in the title, it will be prepended or appended as a link to your PR body.

💡 Use Cases

Consistent Documentation: Every pull request gets a properly formatted JIRA link.
Improved Collaboration: Reviewers and PMs can jump straight from GitHub to the relevant JIRA issue.
Save Time: Contributors don’t need to remember to copy/paste ticket URLs.
CI/CD Ready: Fits neatly into any PR workflow without extra setup.

⚡ How to Use It

Add the action to your workflow:

name: Add JIRA Links
on:
  pull_request:
    types: [opened, edited, reopened]

permissions:
  contents: read
  pull-requests: write

jobs:
  add-jira-links:
    runs-on: ubuntu-latest
    steps:
      - uses: codenamegrant/jira-pr-link-action@v1
        with:
          github-token: ${{ secrets.GITHUB_TOKEN }}
          jira-base-url: 'https://yourcompany.atlassian.net'

That’s it. From now on, PRs will automatically include links to their JIRA tickets.

👉 Try it now on your repos: JIRA Link Action

Find Your Drift (Bolt.new Hackathon)

CodeNameGrant — Thu, 19 Jun 2025 17:48:33 +0000

A visual debt-tracking and simulation app — built with by AI.

Debt isn’t static. Interest rates change. Payments drift. You put money in, you take money out—and suddenly your loan looks nothing like the one you started with. Most debt tools show you a snapshot—one number, one plan. But real debt drifts.I built Drift to help make that visible.
It’s a tool for seeing your debt clearly, tracking how it evolves, and simulating different ways to move forward.

That’s why I built Drift.

💡 What is Drift?

Drift is a finance productivity app that helps you see your debt clearly and understand how it changes over time. It's built to answer questions like:

What does my bond/morgage look different this month?
What if I skip a payment—or make an extra one?
What happens if the prime rate shifts by 0.5%?
How much sooner could I finish paying off my loan?

It gives you one place to visualize and simulate your entire debt portfolio.

⚙️ Built With AI (and vibes)

I built Drift as part of a the Worlds Largest Hackaton using Bolt.new, a platform that turns prompts into working applications. I leaned into the AI-heavy approach—not micromanaging the implementation, but instead focusing on clearly expressing the goal. Sometimes I was even deliberately vague just to see what initiative the AI would take.

The result? A prototype that’s imperfect but real. And most importantly: useful.

🚀 My Goal

This wasn’t just a test of product ideas—it was more a test of process. Could I hand over most of the deveopment to AI, and still ship something real?

I used Bolt.new, gave it vague but intentional prompts, and tried to act more like a director than a developer (which is quite hard as a technical person). I didn’t stress about clean code or best practices (OMG, even harder). I focused on outcomes. The goal wasn’t to craft a scalable system—it was to see if I could turn a complex financial concept into something usable, quickly.

🧪 What I've Learned So Far

1. Letting go is hard (and valuable)

I’m used to shaping every detail of a codebase. Letting AI make decisions—naming things, choosing structure, even picking libraries—felt unnatural. But once I stopped resisting, the project moved faster. The code wasn't always pretty (hell, it still isnt pretty), but the outcome was.

2. Clarity of intent is everything

The more clearly I could describe what I wanted the app to do, the better the AI delivered. I didn’t need to micromanage. I needed to explain my goal like I would to a teammate. That was a shift: less about specs, more about vision.

But even when I wasn’t clear, Bolt.new had my back. Its “Enhance Prompt” feature let me turn stream-of-consciousness brain dumps into structured, actionable instructions. I could write like I think—and let the AI clean it up. That lowered the barrier to trying ideas quickly without slowing down to get the phrasing perfect.

3. You can build something real without building it "right"

I didn’t optimize, architect, or even test properly. I just shipped. And what I shipped does something useful. That's liberating—and a reminder that polish can come later.

4. Debt is weird and personal

Modeling debt isn't just numbers. It’s behaviors. Skipped months, random withdrawals, inconsistent rates. Even just visualizing that mess makes a difference—it makes people feel more in control of something that is usually invisible.

🌱 What’s Next for Drift

Drift is still in development. Right now, it allows users to simulate a single loan in a static way—great for testing scenarios, but just the beginning.

Here’s what’s coming next:

User profiles & multi-account support: I’m currently working on the ability to create a personal profile and track multiple debt accounts of different types—bonds, credit cards, student loans, and more.

Per-account simulations: Once account tracking is in place, I’ll expand simulations so you can test “what if” scenarios on each loan independently, with custom settings.

AI-powered repayment strategies: I plan to integrate AI to suggest tailored repayment approaches based on your loan profile and goals—minimize interest, finish faster, or free up cash.

Future ideas

Long term, I’d love to:

Track prime interest rate changes automatically
Add a “partner mode” so you can plan with a spouse or business partner
Explore bank integrations for live data and auto-tracking (who knows—maybe even budgeting or forecasting tools)

💬 Final Thoughts

Drift is still early—but it’s already useful. It takes debt out of the shadows and puts it on a canvas. You can tweak, simulate, compare. You can see your drift—and once you can see it, you can start steering it.

This was built for a hackathon, but I hope it becomes something more.

Thanks for reading — and if you’ve ever felt overwhelmed by the messiness of debt, I hope Drift gives you a little bit of clarity.

→ Find Your Drift.

Monorepos: Proposing a Monorepo to your team (Q&A)

CodeNameGrant — Thu, 13 Jun 2024 09:01:26 +0000

This post follows a demo I did for my team leaders, where I explained what a monorepo is and how it could address the problems we are currently facing with web frontend dev.
The team leaders include a mix of senior developers and business analysists. So some questions are more technical and some are more general. The questions are in no particular order.

How would a monorepo address the issue of one app being dependent on components from another, potentially causing coupling and making updates to the dependent app more difficult?
There shouldn't be a scenario where apps are dependent on another. Application modules should be a minimal as possible and import feature libraries where all the heavy lifting is done. The feature, which exists outside the application, in a shared space, can then be imported into different applications.

How do you decide what's shared and what's not? "I don’t want anyone using my stuff"
Some components and utilities will be obviously shared, like authentication or common UI components (like navigation, form elements, etc), date management tools or constants. Other components will have to be evaluated as the apps are built.
This will require some thought before hand, What components do we have in our separate apps now that need to be shared? What kind of components are they? Are they presentational or transactional? Are any written for a single use case but can be made generic?
As developers we will have to gauged and decide on a way to pre-emptively decide what should be created as a shared component from the get go. For example if you are creating controls or navigation elements those should probably be shared.

How can a monorepo manage the potential issues arising from poor developer communication and lack of discipline in adhering to pre-agreed rules when using shared or app-specific code?
There are a number of methods both manual an automated that can improve on this issue:

Create clear documentation outlining best practices and expected standards and conventions.
Enforce Code Reviews and PR's by multiple team members to ensure team members adhere to the guidelines. This may sound heavy handed, but will prevent bad practices from spinning out of control.
Module Architecture: Organize the codebase in a modular fashion, where shared components and app-specific code are clearly separated.
Automated Testing and CI: Setup automated testing to catch issues early and use CI pipelines to run linting checks on PRs.
Training and Onboarding: Provide training sessions for new developers to familiarize them with the monorepo, tools and best practices.
Regular update meetings: Schedule regular meetings to discuss ongoing work, updates and issues that team members are having with the monorepo. Foster a culture of open communication where developers feel comfortable discussing potential problems and proposing solutions

How does a monorepo prevent issues seen in previous applications, where a lack of documentation and dependency visibility leads developers to create multiple similar routines instead of modifying exiting ones?
Monorepo tools in general provide a lot more support to the architecture than legacy apps, including dependency visibility. Informing developers what effects the changes they make will have and where

How does a monorepo handle the need to test a shared dependency across all apps that consume it when updates are made?
Any consuming apps would have to under go testing in some form or another to confirm their goals are still being achieved. However much of that testing can be automated by impl unit test or e2e testing with Storybook or Cypress. If you automate the boilerplate testing (eg CRUD), manual testing might only have to be done for edge case scenarios.

How does a monorepo address concerns that updating shared libraries forces all dependent apps to be updated simultaneously, compared to the current approach where libraries can be updated per project, allowing failures to be managed in a smaller, more controlled environment?
Some monorepo tools do support a repo-wide set of dependencies that can be overridden on a per-app/lib basis, however this approach should carefully analysed as it can lead to each app having their own list of deps instead of inherit a list of shared deps and then you are back in dependency hell.

How do we know that by using a monorepo, we arent swapping one set of problems for another? There needs to be more research into the pros/cons from teams that have walked thsi road.
There are many articles that talk about how a monorepo saved them from the same problems that we are facing. It obviously is not a silver bullet and they described challenges and limitations they had to cater for and overcome.
Just like there are articles that promote the joys of monorepos there are also a few that discourage its usefulness, and nothing sparks a debate in the software community like posting articles that a particular subject is the absolute worst. This lead me to the comment sections which yielded what seems to be the most honest impressions of monorepos:

A monorepo doesn't have to be the one-repo-to-rule-them-all, it can also mean on repo for related set of services or applications. Monorepos shouldn't be used to encompass an entire company's codebase unless like Google, Facebook (and others) you also have the engineering resources to do so.
Monorepos can produce complications when scaling, but general consensus is that this is only an issue if you have dozens of developers committing daily to a project with hundreds or thousands of lines of code.
Monorepos do have challenges, its not disputed, but they can be overcome and the benefits are worth it

Sources at the end of the post

What is the breaking point for moving away from our current path?
Continuing our current approach will just exacerbate the problem (of code duplication and dependency hell), leading to the product suite as a whole becoming untenable. We shouldn't wait for the breaking point though before acting. We know there is a problem now, we should begin to proactively resolve it while we have the resources do so. Waiting for a breaking point could mean that when we do address it, we are under time constraints that don't allow adequate investigation or experimentation to impl a new tool correctly.

Is there and automated tool that can migrate our apps into a monorepo and identify the common code that needs to be made sharable?
There are tools to import a standalone repo into a monorepo structure but to conduct code analysis to determine shared/duplicate code would have to be done using a separate tool. This could save time on the migration but it would add the complexity of having to learn and configure these tools for a one-time use. If we had many more repos it could be viable, but I dont think it would add value when migrating the 5/6 we have.

How does using a monorepo change testing by QC of different apps that depend on the same feature change in different environments? Both apps are built together, so it would seem that they are dependent on each other?
Remember that a monorepo does not have to deploy a single build artifact. Each app can result in its own build artifact thats published and deployed independently. So if one of the two artifacts are deployed and testing finds a bug. The other artifact can just carry on.

How does a monorepo address concerns regarding read access to the codebase, particularly in the context of hiring an intern, where specific repo/project access is typically granted?
This is not a problem that monorepo tools tackle. This would be a GitHub issue, and it does not support sub-directory read-only access.
So to answer your question, there is no solution, read access is all-or-nothing.
This would raise concerns if we were applying the methodology to multiple parts of the business (ie. web-clients, mobile-clients, microservices, etc), but since we are only targeting the web-clients (which are so similar that access to one means you can guess whats in the others) it shouldn't be a concern.

Posts about experience with monorepos

Monorepos: Making Git Blame a Family Affair

CodeNameGrant — Wed, 12 Jun 2024 06:13:09 +0000

Monorepos have gained a lot of popularity recently, especially among web developers. There are many resources that cover this topic, so I will briefly cover What is a monorepo and the benefits it provides. At the end I will cite the resources I used to get to this point.

What is a monorepo?

A monorepo is a single repository containing multiple distinct projects, with well-defined relationships. - Monorepo.tools

But a monorepo is about more than just code co-location because without the well defined relationships or boundaries, a monorepo can quickly become monolithic. And a good monorepo is the opposite of monolithic (Misconceptions about Monorepos: Monorepo != Monolith)

Why use a Monorepo?

The opposite of a monorepo is a polyrepo or multirepo; that is a new repo for each project, i.e.. "1 repo = 1 build artifact". This approach is popular because it encourages team/developer autonomy. Developers can dictate their own tech stack, testing strategies, deployment, and (most importantly to them) who can contribute to their codebase.

Now those are all good things, but there are drawbacks to this multi-repo approach that most developers are aware of, but put to down to 'that’s just how it is'. Drawbacks like cumbersome code sharing, significant code duplication and inconsistent practices, cross-repo collaboration problems, inconsistent tooling, dependency hell when updating, automation difficulties, scalability issues, and so on.

"... this autonomy is provided by isolation, and isolation harms collaboration" - Monorepo.tools

So how is a monorepo any better?
For starters, if all your related code is co-located, its much easier to manage dependency updates across all apps, the same shared libraries can be made available to all relevant apps and provide a single source of the truth. Tooling and coding standards can be enforced more consistently. Developers can work across different projects or components more seamlessly, facilitating better teamwork and knowledge sharing. Changes or refactoring that affect multiple components can be made in a single PR, ensuring that all related changes are coordinated and reducing the risk of breaking changes.

While monorepos offer these (and more) benefits, they also come with their own challenges, such as potential scalability issues with very large code bases, increased build times, the need for more sophisticated tooling to manage the codebase's complexity. However, many organizations find that the advantages of a monorepo outweigh the disadvantages, particularly in terms of improving collaboration, consistency, and overall code quality.

Misconceptions

Misconceptions about monorepos (or any tool or technology) often deter teams from adopting this development approach. Lets shed some light on a few and expose the reality of using a monorepo.

Monorepos should contain all a company's code
While large companies like Google or Facebook practice this behaviour it is not the norm. Many teams will only group very similar, closely related apps that can benefit from a shared workspace.

Monorepos mean all projects must be tightly coupled
Monorepos can still support modularity and separation of concerns. In fact many monorepo management tools will advocate for decoupling components and maintaining an modular architecture, otherwise the monorepo is just monolithic.

Monorepos lead to longer build times and slower CI/CD pipelines
With proper tooling and optimization, such as incremental builds and distributed CI/CD systems, build times can be managed effectively. Tools like Nx, Bazel & Lerna utilize incremental builds to only build affected components and caching to prevent building the same thing twice.

Monorepos are harder to scale
While monorepos do present unique scaling challenges, they also offer solutions for consistent and scalable development practices.

Monorepos are harder to secure
Security in monorepos can be effectively managed with proper practices. By only including related projects in a monorepo along with access controls, code reviews and CODEOWNERS can ensure that the codebase remains secure.

The Real Challenges

Just because the many misconceptions are manageable, does not mean monorepos don't have challenges of their own, like migration complexity, tooling adjustments, and workflow changes. Proper planning and best practices are essential to navigate these hurdles and successfully transition to a unified codebase.

Migration Complexity: Moving code from multiple repos into a single repo while ensuring dependencies are mapped and managed correctly can be complex, especially if projects have different histories, dependencies and configurations.
Tooling and infrastructure: Not all your existing build systems, CI/CD pipelines or development tools are designed to handle large monorepos and may require significant updates or replacements.
Development Workflow Changes: Ensuring the effectiveness of code reviews in a larger, more integrated codebase and adapting or redefining branching strategies to suit the monorepo setup while maintaining workflow efficiency
Cultural and Organizational Resistance: Convincing a team that use to working independently to adopt to the new approach and workflow can be challenging. Resistance is common and training may be required while they adjust to the more integrated and collaborative development environment
Consistency and Maintenance: Maintaining consistent coding standards, practices and docs will need to be applied across the repo. Managing and addressing technical debt will be more critical as the monorepo grows.
Learning Curve: New team members may require additional training to understand the structure, tools, processes and workflows of monorepo management and development.

Final Thoughts?

Monorepos are not a silver bullet. And there will be challenges and trade-offs and a culture shift and training and yes, it will be a lot of work. But the benefits could far outweigh those challenges; less time worrying about boilerplate and config per project leads to faster turnaround time on new features or bug fixes, easier maintenance leads to faster adaption of the newer technology trends or tech stacks, more test coverage leads to a more stable product and better code quality which in turn leads to easier adaption by new developers and easier dependency maintenance and more.

Experiences with negative Monorepo research/posts
In my research I did find posts that describe negative experiences with monorepos. Posts that talk about how the benefits of monorepos are not so beneficial and that anyone using a monorepo should abandon all hope. However, nothing stirs up a the software community like telling them that a technology they are using is just the worst. So it’s the comment sections of these post that are more valuable than the articles, with developers denouncing the article and coming to the defence of monorepos, posting how they were able to overcome, mitigate or avoid the problems that the original author encountered.

Sources

Monorepos: From Discovery to Deployment - A Developer's Journey

CodeNameGrant — Mon, 05 Feb 2024 11:48:48 +0000

My first introduction to the concept of a monorepo came when I was search for an alternative to Create-React-App. One option that had potential and a lot of support was Nx, which was (and still is) described and a build system with "First Class support for monorepos". I didn't fully understand the concept of a monorepo at the time beyond that "mono" meant one and "repo" obviously referred to a GitHub repo. So it fell by the wayside in my mind.

A New Problem

A few months later, I started investigating a new problem my team and I were struggling with. For some context, my team and I manage the frontend of product suite. And like many product suites, the webapps follow the same design system and make use of many similar components. Even "under the hood" they all have the same tech stack.

The problem with this methodology (as I'm sure you have realized) is that of duplication. This problem of duplication can be split into 3 parts:

Dependency maintenance must be repeated on each webapp separately and then tested and deployed
It’s too much of a hassle to maintain code sharing libraries, "It’s just easier to implement it myself", leading to duplicated code.
Creating new webapps within the suite results in another identical project that adds to the above problems

Solution Requirements

The solution to this problem is to implement a methodology that makes dependencies and other shared code more accessible to multiple features. This solution would also need to be extendable, so that any new features can inherit any already existing boilerplate code or shared components.

Research

And so the research began... ooh, that sounds to episodic. I explored a number of popular options including; shared config modules, project templates, code generators and shared git submodules are all fine recommendations. But none of them were able to fulfill all the requirements.

Monorepos though, practice consolidating all apps and libraries in one workspace/codebase/repository, simplifying dependency management and ensuring code consistency. With the shared components in one place, representing a single source of truth, any updates to them are synchronized across all apps and libraries. Any new apps will also inherit existing project configurations thereby streamlining development and maintaining code coherence.

Let's Get Going

Hold up now, "One does not simply implement a monorepo". This is a fundamental change to your development architecture and has more far reaching effects than just solving this problem I've described. Each aspect of how you want to implement a monorepo needs to be investigate and tested, proof of concepts should be built to demonstrate that the tools or techniques you want to use are beneficial to your product and team. I say this not to dissuade you from starting, but to make sure each aspect is implemented deliberately, because once you start down the road of a new methodology, it can be harder to backtrack if you encounter issues.

Additionally, having a development plan can help to sell the idea to other team members, leaders and most importantly, sponsors.

This series will cover my journey of migrating from a multi-repo to a monorepo architecture, as well as the research I did, questions I asked and challenges I faced.

Up next

The next part will cover a short intro of what monorepos are, pros and cons, features and challenges. I'll also include a few Q&As from my team about this approach.

Multiple GraphQL Endpoints with Apollo Client

CodeNameGrant — Tue, 09 Jan 2024 09:46:06 +0000

If you are knee-deep in the world of web development, chances are you have crossed paths with GraphQL and Apollo Client. This dynamic duo has revolutionized how developers interact with data on the frontend. However Apollo Client does have a flaw, "How do I connect to multiple GraphQL endpoints using a single client instance? This post will explain a few ways to achieve just that.

Note: For the sake of brevity, 'query' will refer to any GraphQL operation; Query, Mutation or Subscription.

ApolloLink.split()

The native approach is to make use of the split function provided by the @apollo/client. This will enable your link chain to branch to one of two HttpLinks based on the result of a boolean check.

import { ApolloClient, ApolloLink, HttpLink } from '@apollo/client';

const endpoint1 = new HttpLink({
  uri: 'http://endpoint1.com/graphql',
  ...
});

const endpoint2 = new HttpLink({
  uri: 'http://endpoint2.com/graphql',
  ...
});

const client = new ApolloClient({
  link: ApolloLink.split(
      operation => operation.getContext().apiName === 'end1', // boolean check
      endpoint1, // if true
      endpoint2  // if fa
  )
  ...
});

// pass the apiName via the context in your Query
useQuery(QUERY, { variables, context: { apiName: 'end1' } });

In this example, the boolean check is based on a context variable, however the test can be anything. The split function is simple to implement but is limited to only two GQL connections.

Dynamic HttpLink

But now what if a application serves as the frontend for a suite of microservices? Well, by expanding the use of the operation context the endpoint in the HttpLink can be set dynamically.

import { ApolloClient, createHttpLink } from '@apollo/client';

const httpLink = createHttpLink({
  uri: ({ getContext }) => {
    const { apiName } = getContext();

    if (apiName === 'end1') return 'http://endpoint1.com/graphql';
    if (apiName === 'end2') return 'http://endpoint2.com/graphql';
    if (apiName === 'end3') return 'http://endpoint3.com/graphql';
    ...
  }
});

const client = new ApolloClient({
  link: httpLink
  ...
});

// pass the apiName via the context in your Query
useQuery(QUERY, { variables, context: { apiName: 'end1' } });
useQuery(QUERY, { variables, context: { apiName: 'end2' } });

This solution is also relatively simple and allows for expendability as new microservices are added to the suite that the client app has to connect to.

The disadvantage of both of these approaches is that the developer has to include the apiName in the context every time that useQuery. Personally I found this approach lead to a messy implementation. I mean declaring the context object on every request is so repetitive.

Apollo MultiAPILink

I wanted a solution that was more intuitive though, something that removed the need to declare the API every time a useQuery was used, enter @habx/apollo-multi-endpoint-link. This library allows the API to be declared on the GQL query as a directive, instead of every time useQuery is called.

const QUERY1 = gql`
  query Users @api(name: end1) {
    users { id name }
  }
`;

const QUERY2 = gql`
  query Companies @api(name: end2) {
    companies { id name code }
  }
`;

The @api(name: end1) informs the library which endpoint to use based on configuration.
Note: The directive is removed from the query before it is sent to the server.

import { ApolloClient, createHttpLink } from '@apollo/client';
import { MultiAPILink } from '@habx/apollo-multi-endpoint-link';

const multiHttpLink = new MultiAPILink({
  endpoints: {
    end1: 'http://endpoint1.com',
    end2: 'http://endpoint2.com',
    end3: 'http://endpoint3.com',
    ... 
  },
  createHttpLink: () => createHttpLink()
});

const client = new ApolloClient({
  link: multiHttpLink
  ...
});

// Now use the query without any additional api config
useQuery(QUERY1);
useQuery(QUERY2);

The MultiAPILink matches the API name with the relevant endpoint. Since the API is declared on the query, it doesn't have to be repeated in every useQuery, leaving code much cleaner and containing less duplication.

Conclusion

In summary, its definitely possible to have multiple endpoints in a single Apollo Client instance.

Sources

Github: @habx/apollo-multi-endpoint-link
Apollo Link Overview
Apollo Link - Directional Composition

GraphQL Code Generator with TypeScript, React and Apollo Client

CodeNameGrant — Fri, 29 Dec 2023 09:55:23 +0000

GraphQL Code Generator is a powerful, open-source, plugin-based tool for streamlining your development by generating boilerplate code from a GQL schema. It can automate the generation of

Typed Queries, Mutations and, Subscriptions for React, Vue, Angular, Next.js & Svelte, whether you are using Apollo Client, URQL or, React Query.
Typed GraphQL resolvers, for any Node.js (GraphQL Yoga, GraphQL Modules, TypeGraphQL or Apollo) or Java GraphQL server.
… And more!

This was my first experience with GraphQL (GQL) and the codegen tool so I'm going to start with what my situation is and how I went about installing and configuring it to serve my use case. I'll include links to additional info as I go.

My Setup

The web apps I work on are written in React and TypeScript. We recently migrated some of our servers to use GraphQL instead of REST, so naturally I turned to Apollo Client and started writing react hooks that extended the native useQuery or useMutation hooks in Apollo.
Example

import { gql, useQuery } from '@apollo/client';

const CHARACTERS_QUERY = gql`
  query GetCharacters {
    characters {
      results {
        name
        origin {
          name
        }
      }
    }
  }
`;

export default function useCharacters() {
  return useQuery(CHARACTERS_QUERY);
}

This approach became a problem though because obviously the queries were not type safe and so I would need to write out all the TypeScript types, its also a pain to extend! As the application/s grow, I kept manually writing these query/mutation hooks, which became time consuming. There is however a way to use TypeScript with Apollo Client which in turn lead me to the GraphQL Code Generator.

Generating Types

Source Repo
The first step I had to take was to generate the TypeScript types from the GQL schema.

Install the generator's CLI as well as the TypeScript plugin

npm i -D @graphql-codegen/cli @graphql-codegen/typescript

Add a script to your package.json execute the generator

scripts: {
  ...
  "codegen": "graphql-codegen"
}

Create the config file in your root directory named codegen.ts

import type { CodegenConfig } from '@graphql-codegen/cli';

const config: CodegenConfig = {
  overwrite: true,
  schema: "https://rickandmortyapi.com/graphql",
  generates: {
    "src/graphql/generated/graphql.ts": {
      plugins: ['typescript'],
    }
  }
};

export default config;

This config will inform the generator to use the Rick & Morty API to generate a file (graphql.ts) using the TypeScript plugin. This will result in the GQL schema being converted into basic TypeScript Types.

Generate React/Apollo Hooks

Source Repo
The next step will instruct the generator to use predefined queries (or mutations) to generate hooks that execute the queries using Apollo Client.

Install the TypeScript-Operations and TypeScript React Apollo plugins.

npm i -D @graphql-codegen/typescript-operations @graphql-codegen/typescript-react-apollo

Create src/graphql/documents.graphql to store the queries to generate hooks for.

query Episodes {
  episodes {
    results {
      episode
      name
    }
  }
}

query Characters {
  characters {
    results {
      name
      species
    }
  }
}

Update the codegen.ts file to use the above file and plugins to generate the result

import type { CodegenConfig } from '@graphql-codegen/cli';

const config: CodegenConfig = {
  overwrite: true,
  schema: "https://rickandmortyapi.com/graphql",
  documents: './**/*.graphql',
  generates: {
    "src/graphql/generated/graphql.ts": {
      plugins: ['typescript', 'typescript-operations', 'typescript-react-apollo'],
    },
    config: {
      withHooks: true
    }
  }
};

export default config;

The GQL documents can take different patterns. However, after some experimentation, I found that for my use case its easier to just keep them all together in a .graphql file. The config attribute is where plugin attributes are specified. The withHooks attribute is used by typescript-react-apollo.

npm run codegen
Once you have run the generator again, you will see that the generated graphql.ts file now contains hooks that execute the various query variants from Apollo based on the queries we declared, ie useEpisodesQuery, useEpisodesLazyQuery, useEpisodesSuspenseQuery, etc.

Generate Hooks near operational files

Source Repo

As I'm sure you noticed from the source code, the app is structured with feature directories but our types and hooks are all generated in single file. However, I want the types to be in their own file to be used anywhere in the app but the documents and generated hooks must be in the feature directories where they are being used.

To achieve this, I used the Near Operation File Preset plugin. This plugin scans a directory for documents and generates the hooks files in the same location.

First install the plugin

npm i -D @graphql-codegen/near-operation-file-preset

In order to use this preset, you need to add 2 outputs to your codegen.ts file:

The first, is the base types, generated by typescript plugin.
The second, is the one that is in charge of generating types per document.

import { CodegenConfig } from '@graphql-codegen/cli';

const config: CodegenConfig = {
  overwrite: true,
  schema: '',

  generates: {
    './src/types.ts': {
      plugins: ['typescript']
    },
    './src/': {
      documents: './**/*.graphql',
      preset: 'near-operation-file',
      presetConfig: {
        extension: '.generated.ts',
        baseTypesPath: 'types.ts'
      },
      plugins: ['typescript-operations', 'typescript-react-apollo'],
      config: {
        withHooks: true
      },
    }
  }
};

export default config;

npm run codegen
This will result in a *.generated.ts file being created for each .graphql in any directory under src.

Final Thoughts

The GraphQL Code Generator is in fact a powerful tool that has simplified my development process. It has a large plugin library that supports many languages and presets and is generally well documented.

Stop Git from tracking file changes

CodeNameGrant — Fri, 07 Jul 2023 10:56:42 +0000

In this short post I'll explain how and why I like to (sometimes) stop Git from tracking file changes.

Why would I want such a thing?

A simple but real world use case would be when your LOCAL project config differs from the config required in PROD.

Take a look at this .npmrc file. Its configured to make use of use an environment variable ${NPM_GIT_PAT} as the authToken when connecting to the GitHub Package registry.

@my-private-scope:registry=https://npm.pkg.github.com/
//npm.pkg.github.com/:_authToken=${NPM_GIT_PAT}

Now the file in this state is ready for PROD. When it runs (via GitHub Actions) the NPM_GIT_PAT environment variable will be declared and populated by a GitHub secret and NPM will be able to install dependencies from a private repo.

But what about your LOCAL environment? You need to set that authToken to your own private PAT so you can access those private repos. By telling git to stop tracking changes on the npmrc file, you can edit it and paste your private token in there without the risk of later accidentally committing it your repo.

How

The how is the easy part, git provides a command that let you tell it to stop tracking specific files or folders.

git update-index --assume-unchanged path/to/src/file

This should only be used on files that are already in your repo, if you want git to ignore files from the get-go, add them to you .gitignore file instead.

"Wait, how do I undo it?"
Its just as easy, replace --assume-unchanged with --no-assumed-unchanged and you're set.

git update-index --no-assume-unchanged path/to/src/file

Forem: CodeNameGrant

Domain-First Nx Monorepos: Using `packages/` to Make Ownership and Boundaries Obvious

Flat libs/ worked… until it didn’t

A concrete example (the kind that trips new people up)

Implementing packages/: make the repo explain itself

Why packages/?

Module boundaries: make the “right” thing the easy thing

High-level migration plan (draft)

Bonus benefits

1) Simpler GraphQL Code Generator workflow

2) Apollo type policies become easier to wire consistently

3) Generators become much more predictable (domain + type = obvious destination)

4) Possible future win: more predictable implicit libraries

Closing

Flip Your CI Like a Switch: Instantly Toggle Flags with GitHub Actions Variables

What Are GitHub Actions Variables?

Example: Controlling Nx Build Flags

Monorepos: A Year in Review

One Repository to Rule Them All

Our Approach

The Tech Stack: Nx & Nx Cloud

Stories from the Journey

Code That Could Stay Put

Side Effects We Actually Liked

Lessons Learned

Conclusion

Supercharging Your Workflows with Local GitHub Actions

What Are Local Actions?

Demo: Bootstrap Node Environment

.github/actions/bootstrap-node/action.yml

Usage in a workflow

Exciting Use Cases for Local GitHub Actions

Why Use Local Actions?

Wrap-Up

Link Pull Requests to JIRA Issues with Ease

🔗 What It Does

💡 Use Cases

⚡ How to Use It

👉 Try it now on your repos: JIRA Link Action

Find Your Drift (Bolt.new Hackathon)

A visual debt-tracking and simulation app — built with by AI.

💡 What is Drift?

⚙️ Built With AI (and vibes)

🚀 My Goal

🧪 What I've Learned So Far

1. Letting go is hard (and valuable)

2. Clarity of intent is everything

3. You can build something real without building it "right"

4. Debt is weird and personal

🌱 What’s Next for Drift

💬 Final Thoughts

Monorepos: Proposing a Monorepo to your team (Q&A)

Monorepos: Making Git Blame a Family Affair

What is a monorepo?

Why use a Monorepo?

Misconceptions

The Real Challenges

Final Thoughts?

Monorepos: From Discovery to Deployment - A Developer's Journey

A New Problem

Solution Requirements

Research

Let's Get Going

Up next

Multiple GraphQL Endpoints with Apollo Client

ApolloLink.split()

Dynamic HttpLink

Apollo MultiAPILink

Conclusion

Sources

GraphQL Code Generator with TypeScript, React and Apollo Client

My Setup

Generating Types

Generate React/Apollo Hooks

Generate Hooks near operational files

Final Thoughts

Stop Git from tracking file changes

Why would I want such a thing?

How

Flat `libs/` worked… until it didn’t

Implementing `packages/`: make the repo explain itself

Why `packages/`?

`.github/actions/bootstrap-node/action.yml`