LogoLogo
  • 👋Cal.com Handbook
  • The Company
    • ❓What is Cal.com?
    • 📈Mission, Vision and Values
    • 🅰️Glossary
    • 📈Organization Chart
  • HR & Careers
    • 👷Contract-to-hire trials
    • 🛫Onboarding
    • 🏆IC Levels
      • ⛰️Engineering Levels
        • 🕵️IC1 Engineer (Code Cadet)
        • 👷‍♀️IC2 Engineer (Code Craftsperson)
        • 🧘‍♀️IC3 Engineer (Code Connoisseur)
        • 🧙‍♂️IC4 Engineer (Code Wizard)
    • 💡Sharing your views
    • 💸Bonus & Equity Structure
  • Policies
    • 🏖️Vacations
    • 💳Expenses
    • 🗣️Communications
  • Engineering
    • 🔔Managing Notifications
    • ⭐Valuable Bookmarks
    • 🐛How to report issues
    • 💻How we work on Tickets
    • 🔥What to do during Emergencies
    • ✅PR Reviews
    • ☑️Self-reviews
    • 📚Keeping Docs up-to-date
    • 🌐HTTPS & Subdomains
    • 🎯Best practices
      • Data fetching
      • Avoid Prop Drilling
      • Prefer defaultHandler for simple API handlers
      • Prefer inferred types over explicit ones
      • Prefer early returns
      • Avoid comparing multiple values with `includes`
      • Validate using zod instead of type casting
      • Prefer Composition over Prop Drilling
      • Prefer ternaries over Short Circuiting “&&” for React Components
      • Don't modularize prematurely
      • Only select data you need
      • Disallowing the use of unrestricted Metadata fields
      • E2E Tests Best Practices
    • 💻Codebase
      • 🔓Keeping the lock file in sync
      • 🚫Git Private Submodules
      • 🏎️Monorepo / Turborepo
      • 🌝Deploying to Production
      • ☁️Deployment
      • 💻Debug Desktop App
      • 🚩Enabling/Disabling Features
    • 🔺Resolving failed migration on Vercel Preview
    • 🔦Cal.com Status Page
  • Customer Success
    • 💟Tone
  • Marketing
    • 🎬Media
    • ☝️How to add a new Tip to Sidebar
  • 🤲Sales
    • Operations Stack
Powered by GitBook
On this page
  • For core-contributors, how to ensure a consistent setup for submodules
  • For external contributors

Was this helpful?

  1. Engineering
  2. Codebase

Keeping the lock file in sync

These instructions will help to ensure we don't introduce unwanted changes to the lock file.

PreviousCodebaseNextGit Private Submodules

Last updated 1 year ago

Was this helpful?

Since we use some private modules alongside the public monorepo, we have some special requirements when dealing with lock file changes. This can be confusing for and there's around it as well.

The rule of thumb is: As long a we don't introduce new packages (either in a package.json or monorepo package) there shouldn't be any lock file changes in a core contributor local environment.

For core-contributors, how to ensure a consistent setup for submodules

  • Make sure you're on main

    git checkout main
  • Make sure you have private submodules initialized and updated

    ./git-setup.sh website console
  • Run yarn install to see if there are lock file diffs

    yarn

For external contributors

Please refer to the section in our .

💻
🔓
some contributors
some discussion
"Guidelines for committing yarn lock file"
CONTRIBUTING.md guide