## The problem
Let’s imagine that we need want to display an image on our webpage in an aspect ratio of 16 by 9. Now, this would be easy if we have a source image that has the same aspect ratio. But as a developer, you don’t always have control over this. You’ve received the following image:

![A single person in frame](/img/articles/face-cropper-single-face.png)

Luckily, with modern CSS, we can easily make this 16 by 9 with the following to CSS lines:

```css
img {
  aspect-ratio: 16 / 9;
  object-fit: cover;
}
```

Once doing this, we see the following result in the browser:

![Half a person's face in frame](/img/articles/face-cropper-single-face-cropped.png)

Oh no! We can’t see the face anymore. This is because by default the [object-position](https://developer.mozilla.org/en-US/docs/Web/CSS/object-position) is set to `center center` which will center the crop on both the x-axis and the y-axis. No problem, we can just update our CSS to:

```css
img {
  aspect-ratio: 16 / 9;
  object-fit: cover;
  object-postion: top center;
}
```

But wait, now the bottom of the face isn’t visible:

![Top half of person's face in frame](/img/articles/face-cropper-single-face-cropped-manually-positioned.png)

We can ultimately fix the `object-position` by passing pixel or percentage values to get the crop just right. This is however a painstaking process that you would have to do for all your images. Besides that, what if the images can be random and you can’t cover all edge-cases?
**We need a way to crop and position the crop just right for the face to be in view.**
## The Face Detection API to the rescue!
The Face Detection API, a spinoff of the [Barcode Detection API](https://developer.mozilla.org/en-US/docs/Web/API/Barcode_Detection_API), is at the time of writing only available on Chrome after turning on a feature flag. You can do this by going to `chrome://flags`, searching for `#enable-experimental-web-platform-features` and turning it on.

![Chrome settings screen to enable experimental features](/img/articles/face-cropper-chrome-flags-experimental.png)

Your browser will restart and the Face Detection API will be available

So what can you do with this API? You can pass an image and it will return you the _bounding box_ of the detected face(s). It will also give you an array of _landmarks_. These _landmarks_ consist of detected eyes, noses and mouths per detected face. Today, we’re just focussing on the actual faces. If we run the API on the previous image, we get this result:

```json
[
  {
    "boundingBox": {
      "x": 230.64181518554688,
      "y": 208.36253356933594,
      "width": 292.52178955078125,
      "height": 292.52178955078125,
      "top": 208.36253356933594,
      "right": 523.1636047363281,
      "bottom": 500.8843231201172,
      "left": 230.64181518554688
    },
    "landmarks": [
      // removed from example
    ]
  }
]
```

So, we can now use this data to know where to position our crop, right? Well, that’s what I thought. There is a pitfall. These values are referring to the intrinsic size of the image you pass. In our demo, we scaled down our image. Therefore, these values need to also be scaled down.
### Mapping the intrinsically based values to the scaled-down based values
First, we need to know the width and the height of the intrinsic image. We can do this with the following part of the code:

```jsx
async #getIntrinsicImageNodeSize() {
    const that = this;

    return new Promise((resolve) => {
      var url = this.imageNode.src;
      var img = new Image();
      img.onload = function () {
        const { width, height } = img;

        that.intrinsicImageNodeSize = { width, height };
        resolve();
      };

      img.src = url;
    });
}
```
Once we have the intrinsic width and height, we can map our face detection bounding box:

```jsx
#getBoundingBoxForFace() {
    const imageNodeBoundingBox = this.imageNode.getBoundingClientRect();

    return {
      top:
        (faceDetectionBoundingBox.top / this.intrinsicImageNodeSize.height) *
        imageNodeBoundingBox.height,
      bottom:
        (faceDetectionBoundingBox.bottom / this.intrinsicImageNodeSize.height) *
        imageNodeBoundingBox.height,
      left:
        (faceDetectionBoundingBox.left / this.intrinsicImageNodeSize.width) *
        imageNodeBoundingBox.width,
      right:
        (faceDetectionBoundingBox.right / this.intrinsicImageNodeSize.width) *
        imageNodeBoundingBox.width,
      width:
        (faceDetectionBoundingBox.width / this.intrinsicImageNodeSize.width) *
        imageNodeBoundingBox.width,
      height:
        (faceDetectionBoundingBox.height / this.intrinsicImageNodeSize.height) *
        imageNodeBoundingBox.height,
    };
}
```

In essence, what we’re doing is taking the face detection bounding box that is based on the intrinsic size of the image and calculating what the pixel values would be for our scaled-down image. Cool, we now have the following values:

```json
{
  "top": 107.68089590146559,
  "bottom": 258.8549473488978,
  "left": 119.1947456238351,
  "right": 270.36880860493204,
  "width": 151.174062981097,
  "height": 151.1740514474322
}
```

We can now take these values to, for instance, draw a box on the detected face(s) for easier debugging:

![Red squares on the face of the single person in frame](/img/articles/face-cropper-single-face-detection.png)

If you want to learn more about this API, the Barcode Detection or Text Detection API, you can watch my Friday Tip on _[A first look at the Shape Detection API](https://www.youtube.com/watch?v=ZnSTi3Wbs7g)_. **While you're there, make sure to subscribe!**
## Using the face detected bounding box to set the crop position
Now that we have these values, we can set the `object-position` x and y value to be the top and left of the face detected bounding box. A downside to this, however, is that we need to recalculate these values everytime the image on the page resizes. A smarter way would be to set these value percentage based for both the debugging boxes and the actual `object-position` value. Let's set to percentages for the `object-position` property:

```jsx
#setObjectCrop() {
    const boundingBox = this.#getBoundingBoxForFace();
    const { width: imageNodeWidth, height: imageNodeHeight } =
      this.imageNode.getBoundingClientRect();

    const { top, right } =
      this.#mapFaceDetectionBoundingBoxFromIntrinsicSize(boundingBox);

    const { setObjectFit, setObjectPosition } = this.options;

    if (setObjectPosition) {
      this.imageNode.style.objectPosition = `${Math.floor(
        (right / imageNodeWidth) * 100
      )}% ${Math.floor((top / imageNodeHeight) * 100)}%`;
    }

    if (setObjectFit) {
      this.imageNode.style.objectFit = "cover";
      this.imageNode.style.aspectRatio = "16 / 9";
    }
}
```

We basically use the top and left values of the face detected bounding box and calculate what percentage those values are based on the height and width of the image respectively. We can now see the smartly cropped face in view:

![Cropped face of a single person in frame](/img/articles/face-cropper-single-face-cropped-with-detection.png)

Great, that seems to work! Whichever image I use, I can be assured that the face will be in view. But what about multiple faces?
## Creating a combined bounding box for multiple faces
Luckily, we can quite easily implement the functionality to get the combined bounding box for the detected faces:

```jsx
#getOuterBoundingBoxFromFaces() {
    const sortedFacesByTop = this.faces.sort(
      (a, b) => b.boundingBox.top - a.boundingBox.top
    );
    const sortedFacesByBottom = this.faces.sort(
      (a, b) => b.boundingBox.top - a.boundingBox.top
    );
    const sortedFacesByLeft = this.faces.sort(
      (a, b) => b.boundingBox.left - a.boundingBox.left
    );
    const sortedFacesByRight = this.faces.sort(
      (a, b) => b.boundingBox.right - a.boundingBox.right
    );

    const top = sortedFacesByTop.at(-1).boundingBox.top;
    const bottom = sortedFacesByBottom.at(0).boundingBox.bottom;
    const left = sortedFacesByLeft.at(-1).boundingBox.left;
    const right = sortedFacesByRight.at(0).boundingBox.right;

    return {
      top,
      bottom,
      left,
      right,
      width: right - left,
      height: bottom - top,
    };
}
```

Firstly, we get the highest top, lowest bottom, farthest left and farthest right of all the detected faces. We can then easily calculate what the width and height have to be for the combined bounding box.

![Sketch of edges of group](/img/articles/face-cropper-combined-bounding-box-sketch.png)

Then, we use those values to set the value for the `object-position` just like we did earlier. A short demo for this image:

![Multiple people in frame](/img/articles/face-cropper-multiple-faces.png)

Cropping this normally would look like this:


![Multiple people in frame with the right person cut off](/img/articles/face-cropper-multiple-faces-cropped.png)


So we detect all their faces:

![Multiple people in frame with a red box on their faces](/img/articles/face-cropper-multiple-faces-detection.png)

And use the combined bounding box to smartly crop the image:

![Multiple people in frame cropped with all their faces visible](/img/articles/face-cropper-multiple-faces-cropped-with-detection.png)

## Looking back
Naturally, we can optimize this demo even further with, for instance, margins for the crop and more. Next to that, this is in no way a production-ready solution due to it just working on Chrome behind a feature flag.

More important is that this shows just how powerful the browser can be. By combining two techniques, the Face Detection API and the `object` properties combined with the `aspect-ratio` property in CSS, we create an incredibly powerful tool. You can view the demo with the end result with examples [here](http://face-cropper-demo.davebitter.com/). You can view the code of this demo [here](https://github.com/DaveBitter/face-cropper-demo).

Smart cropping with native browser Face Detection

* "Yeah, that was written two years ago... We need to rewrite that...”
* "What were those developers thinking?”
* "Ah, that's legacy code...”

  * "What? It's not even a few years old!”

* "Let's write our own, that one is super complex and it's easier to make our own...”

Then two years later, the same things are said about the new better solutions these developers made. The larger the projects, the more this seems to happen. Naturally, large projects can become quite complex and therefore the solutions can become quite complex. It does feel however that it's more the rule than an exception. Thinking about this, a couple of questions came to mind:
* Why does this happen so often, so quickly?
* How quickly does something become "legacy code”?
* How can we prevent this for our development teams and own code?
Now, I've got some ideas for my own on these questions, but what does the development world think is the reason for all of this.
## Time for research
I have spoken to people in technology with a variety of skills, experience and roles. Time to find out how they think about these questions, what tips they have to prevent these issues and more.
### The startup mentality
Whether you work at a small startup or a large corporation, there seems to be a common reason why unsustainable solutions are written. Often, the credo is to deliver early, deliver much and keep on getting funding/budget. Especially in front-end development, it's easy to fall into this trap. It's very easy to deliver quickly in front-end development with flashy UI and new features. Almost always this means you have to sacrifice some things. Scalability, documentation and sustainability are some of those things. It's hard to sell these to management who first need to see quick positive results before thinking about long-term consequences. A lot of temporary solutions are made to stay on track with the deadlines.

![I'll fix it later... he, in fact, did not fix it later...](/img/articles/fix-it-later.png)
> Nothing is as permanent as a temporary solution.

However hard it is, developers need to make time for this. It's naive to think you will get time for this (soon). Developers need to explain, and managers need to understand, that these things are part of building a product that can't be skipped over. If you do, you will create an instant debt that will have an interest.
### Relying fully on frameworks in a coupled way
Front-end development is always mentioned in one breath with frameworks. The rise of frameworks in the past decade(s) has allowed the front-end world to evolve at a rapid pace. Developers can create state of the art user experiences with relatively low effort.

A downside of these frameworks is that, more often than not, developers write their solutions in a very coupled way. Framework-specific logic is completely intertwined with non-framework-specific logic. This makes it hard to migrate to new (versions of) frameworks. By decoupling this logic into smaller modules you can encapsulate features into standalone features. This makes it easier to refactor small parts of your application without having to do a "big bang refactor”.
### ~~Getting~~ Making time
It's incredibly hard to get time to refactor "legacy code”. There is often a communication gap between developers and their product owners/management. Naturally, it's easier to get time for a fancy new feature than to make "invisible” updates. This communication gap can lead to a lot of frustration. Both "sides” have to work on this, however.

As a developer, you often fall into the trap of making your case to non-technical people with technical terms. For example, try explaining to a non-technical person that you need to refactor your global state manager to a new framework that makes it easier to persist state client- and serverside. These terms are not difficult for developers to understand, but if you are not a developer, they can sound like a foreign language.

![Making your manager fall asleep with technical terms](/img/articles/making-your-manager-fall-asleep.png)

Instead, try to not just "dumb down” what you are explaining, but ask yourself if you need to explain it at all. A better way of communicating this to your manager is to explain the benefits for the users of their product. We need to use this new technique as it will allow us to remember choices the user made across different pages and moments in time. This way we can personalise the user experience and work on improving the conversion rate. You see, this turns it into an understandable story that clearly shows the business value.

Both sides need to keep an eye on miscommunication due to technical terms. On the one hand, developers need to work on how they communicate desires, on the other hand, managers need to be vocal when a developer is not making any sense to them and ask for an understandable explanation.
### Having a process in place
A big question is how seriously does your organisation take this? There's no denying that regular updates and refactors are vital to delivering a solid product. However, we do see that often the work and priority of this are heavily underestimated. There needs to be a process in place to ensure this won't get overlooked.

Luckily, you can automate parts of this. It might be wise to set a standard in your organization and automate audits in your CI/CD to monitor with tools like dependa-bot. This way, problems become visible earlier on, are more tangible and you don't see them a year after your last check.

Next to this, teams working with Scrum should make this part of their standard sprint. Update early, update often is one of the best things you can do as a team and organization. I've seen it so many times that teams postpone updating their applications to the latest versions of external and internal dependencies. You can postpone this all you want, but you're accumulating debt. This ends up with an update/refactor or rebuild discussion crippling any other work, like new features, that need to be built. You'd be surprised how many "legacy applications” can be prevented to rebuild if there was a process in place to keep them up to date.
### Really smart developers will cause issues
It may seem like a counterintuitive statement, but a major downfall of very smart developers is that they may tend to build rather complex solutions. These solutions may even be unnecessarily complex, difficult to maintain and have no/little tests in place. The problem with these solutions is that, although they might work well and are very impressive, you run into trouble once these developers leave your organization. Suddenly, there are these overly complex solutions that are difficult to fully understand by other developers.

Naturally, this can be countered with well-written documentation, knowledge transfers and similar solutions, but you will never fully understand how it works as the original developer did. There is an acronym that we like to use called K.I.S.S. (Keep It Simple Stupid). Although this may seem overly obvious, this credo is not followed in a lot of situations. It's actually quite hard to keep your solution simple and easy to understand. The extra time invested in this will be worth it in the long run as developers not using an existing solution because it's they can't grasp what it offers or how it works is such a shame. A new solution, maybe equally as complex, is written and the cycle continues.
## Front-end is in its infancy
![Two front-end developers walk into a bar. They've got nothing to talk about...](/img/articles/two-front-end-developers-walk-into-a-bar.png)

I can go on and on about reasons for the _"The infinite legacy cycle in front-end”_ phenomenon, but it comes mostly down to a simple observation. Front-end is in its infancy compared to, for instance, Java and .NET by about 30 years. These platforms went through similar cycles and became more standardised and agreed upon over the years.
### We are not really focused on design patterns
Naturally, we have design patterns in front-end, but we tend to have a lot. Front-end is susceptible to whatever a developer wants to do. Many different opinions on how we should do things. This leads to many discussions and frameworks implementing their own.

Let's compare this to the back-end landscape. Some patterns are over 60 years old! These patterns work, stood the test of time and are not under debate. How different is that from front-end? Can you imagine us having similar patterns undisputed patterns? This would help greatly with our applications withstanding the test of time past two years.
### Frameworks
Let's take frameworks as an indicator. One of the big reasons for certain front-end applications becoming "legacy” is the vast number of frameworks popping up. Suddenly, the framework you used two years ago isn't considered good enough anymore. Although these framework wars spark innovation, they make the front-end landscape change rapidly. My feeling is that this curve is slowly calming down, but you need to be aware of this when starting new applications. You want to make sure that you don't choose a framework as a developer because it looks like the best solution **now**, but can stand the test of time to a certain degree.
### Rendering strategies
![Rendering schema from SSR to CSR to SSG to SSR](/img/articles/rendering-schema.png)

Another example is rendering strategies. Ever noticed we tend to go in circles? We started with rendering all applications server-side. The rise of SPA frameworks moved everything to client-side rendering. This caused issues that we tried to resolve with static site generation. This was cumbersome so one of the latest frameworks, [Remix](https://www.davebitter.com/articles/first-look-at-remix), is moving back to web fundamentals with server-side rendering. The front-end community figuring this out over the past decade has caused an immense rise in "legacy applications”.
### We'll get there
We're still figuring things out. That's fine, tremendous strides are being made to solidify patterns, better the developer and user experience and more. These things take time. It's our job as front-end developers to be cognizant of this and try to not keep jumping to the latest and newest thing right away.
## Closing thoughts
There is no magic way to prevent your applications to become "legacy”. There are however things you can do to mitigate this as much as possible. This is a joint effort between developers and business. Front-end applications are incredibly complex. We need to recognize this and put checks in place to prevent getting stuck in this cycle.

The infinite legacy cycle in front-end

## The problem with waterfall

![Interaction design (ID), visual design (VD) and front-end development (FED) working with a waterfall approach](/img/articles/design-front-end-development-waterfall.png)*Interaction design (ID), visual design (VD) and front-end development (FED) working with a waterfall approach*

A traditional way of collaboration between visual design, interaction design and front-end development is the waterfall technique with a review moment. Visual and interaction designers work together to produce a static design. Front-end developers translate this design into interactive components. At the end of this process, there's a moment to review the implementation by all parties.

The problem with this approach is that design and front-end development produce output for vastly different mediums. Often, designs are made in tools like Sketch, Figma or the Adobe suite. The tool outputs static images. For front-end development, the output is for a virtually unlimited variation in mediums. There are functionalities in these design tools to create interactive designs, but they don't offer the vast range of devices, browsers, screen sizes and other factors.

> In front-end development there is no one-size-fits-all

This causes issues when a design is made for a limited number of these variations (usually being a mobile, tablet and desktop viewport). Design issues or potential opportunities arise late in the production cycle. I often see that the time and capabilities to resolve these are limited at this stage. Most of these issues can be prevented by not just leveraging design handoff in the browser, but changing the approach to how design and front-end development work together.
## Several stages of design and development collaboration

![Interaction design (ID), visual design (VD) and front-end development (FED) working together in different stages of producing components](/img/articles/design-front-end-development-fluid.png)*Interaction design (ID), visual design (VD) and front-end development (FED) working together in different stages of producing components*

Front-end development at my company Mirabeau, a Cognizant Digital Business, is in the same unit as visual design and interaction design. This structure has been set up for tight collaboration between these disciplines. In projects as a front-end developer, I've identified six major stages where design and front-end development can take advantage of each other's view, experience and skillset.

### 1. Concepting
During the concepting phase, design often works with stakeholders and users to identify what the problem is and how they can solve it. Even though there isn't a line of code being written yet, this is where front-end development can help in identifying issues early on and, perhaps even more important, suggesting potential opportunities. For example, there is an ask for an incredibly important alert component. Did you know that on some mobile browsers you can use the phone's vibration to give haptic feedback? By involving front-end development in the concepting phase, these kinds of opportunities can contribute to a better solution for the user.

### 2. Design production
After this front-end development can assist design during the actual production phase. A tight collaboration in this phase adds a lot of value by having a back-and-forth between disciplines. Design can actively seek input from front-end development when taking the solution from concept to an actual design that will be implemented. Due to diversity in view, experience and skillset, both design and front-end development push each other to see problems through different eyes. This always leads to a better thought-out and considered result.
### 3. Design review

Once the design production is done, there is a moment for front-end development to do a final review. Design and front-end development go over the proposed solution, see if everything is clear and whether there are still improvements to be made. For example, front-end builds in reusable components and sizings. Does the proposed design suddenly use vastly different sizings? Is there really the need for a new kind of dropdown component? These questions can be asked to ensure consistency, preventing reinventing the wheel and more.

### 4. Browser handoff
Next, front-end development builds the design. This is where the most vital part of the approach lies. There is no way you can predict and prevent all potential issues you will encounter. With real content or data, the fluidity of the web and different context in which design is used you're bound to find problems. For example, a narrow component with a welcome message does not fit on an in-between screen size due to a longer name. During the design phase, two things weren't accounted for. First, a design was made for mobile and tablet. What about right in between? Second, during the design phase, the default persona was used with a name eight characters long. With production users, there can be a wide range of lengths of users' names.

Luckily, design and front-end development have been working tightly together online or in person. They work together in the browser to identify the specifics of the issue, brainstorm options and build the solution in the browser together. The disciplines come up with the solution together when there is an unusually long name. There is no need to update all the actual designs. In the end, we all work together to build for the web. Our single source of truth lives there and this is where we collaboratively craft our final version.
### 5. Development review
After front-end completes their work, there is a final session between design and front-end development to dot the i's and cross the t's. I've noticed a lot of designers I worked with who are really appreciative of this moment. Together design and front-end development go over the final implementation. Are there some things that front-end development missed? Are there some things the design would like to alter based on the actual interactive product?

> Here's where we perfect our creation together

I've asked my colleague and interaction designer Virginia Rispoli what she thinks about browser handoff and the development review. Virginia loves that you can finally see the interactions and designs in action. This usually allows both design and front-end development to look at the ideas, features and components a bit more critically. To her, this is the moment where the superpowers and skills of design and front-end development come together. If both are open enough to discuss and rethink their ideas, the result is always better than the initial idea.

These points are further solidified by my colleague and visual designer Alexander Munz. He states that the advantages of design handoff in the browser are diverse. It’s a great opportunity to collaborate between development and design; seeing, feeling and anticipating behaviours on an iteration of the end-product offers the opportunity to discover, change and adapt quickly. Design handoff in the browser and collaboration offers the opportunity to learn from each other, create better solutions and do this a lot quicker then re-designing a static screen in your design tool of choice. The team saves time, which gives the client more value for their money and they can even be part of the fun if they choose to be.
### 6. Documentation
Lastly, we document our single source of truth. There's already a static design, so what's the point of documenting the component again? Besides developer-documentation on how to work with the component, we want to document the interactive component in a way where you can view it in all the contexts you'd like.

![Storybook showcasing a badge component](/img/articles/storybook.jpg)*Storybook showcasing a badge component*

A good solution for this is an interactive component showcase library, the best-known among them being [Storybook](https://storybook.js.org/). Storybook offers a flexible UI for both design and front-end development to not just view and interact with the components, but alter them as well. With the wide range of features and plugins you can dynamically change the content (e.g. change the name in a component to more characters), test different screen sizes and more. This fluid version of showcasing the design implemented in interactive components is most flexible.

Finally, documenting all existing interactive components and variations gives the team a place to reference. For example, design might check whether there's already a dropdown component, developers look up what variants they can use and copywriters can see what happens when they change certain labels.
## Get started in your team
Excited to try a similar approach? There are a few people you might want to open the discussion up to. First, open up the discussion with your design and front-end development team. Try to see if you ever ran into some of the issues I mentioned above. In my experience, design is often very open to more moments of working together with front-end development.

Second, you might work in a scrum team. Propose this new way of working together as design and front-end development to your project manager and scrum master. It might be a bit too much to completely overhaul the current workflow you have. Start with one new component. If it works, try it again and again.

Finally, you might have to persuade certain stakeholders. This will be on a case-by-case basis. Time, costs and resources however are an often-heared concern. You are asking for more time together to craft the best work possible. An immense benefit of this new approach is that you actually resolve many of these concerns. You tackle (potential) issues early on. This costs time at the start of the trajectory, but you earn this back by mitigating the surfacing of these issues at the end or even in production. You could use the components you build while trying out this workflow as examples to get them on board.

Try to see if this way of working works well for your team. This doesn't work for you? That's fine as well. The goal is to further improve cross-discipline collaboration and ensure you build your best work together!

Design handoff in the browser

I am a Developer Advocate & Senior Front-end Developer/Consultant. Here, you can find my resume, a collection of my articles covering a wide range of topics and get in contact.

Front-end

As a reference, the mono-repo might look something like this:
```
packages/
├── foo-pkg
│   └── package.json
├── bar-pkg
│   └── package.json
├── baz-pkg
│   └── package.json
└── qux-pkg
    └── package.json


```
In its essence, [Manypkg](https://github.com/Thinkmill/manypkg) is a linter for `package.json` files in Yarn, Bolt or pnpm mono-repos. You can use it to automate these chores. Simply run `yarn add @manypkg/cli` and you can run the following commands in your pre-commit hooks and pipelines:
## `manypkg check`
I use this to check whether all `package.json` files are alphabetically sorted, there are internal and external mismatches between packages, there are invalid dev and peer dependency relationships, invalid package names and more. You can have a look at the checks [here](https://github.com/Thinkmill/manypkg#checks).
## `manypkg fix`
This will run the check and try to automatically resolve the issues it finds. Usually, it’s a wise idea to run this command in your pre-commit hook. That way, your pipeline won’t fail mid-way because of a minor issue.
## `manypkg run <partial package name or directory> <script>`
With this command, you can run a script in a `package.json` file of a particular package in the mono-repo. Let’s say you have a package that has a script that runs a test for that package. You can then run `manypkg run your-package some-tests`.
## `manypkg exec <cli command>`
This will let you run a CLI command in each of the packages. For example, you can run `yarn manypkg exec rm -rf dist` to remove the dist folder in every package in the mono-repo.
## Verdict
Although the latter two are nice to have, the check and fix commands are vital in any mono-repo to me. It not only helps me but gives me peace of mind that a large group of developers can work on the mono-repo and we have checks and tools in place to make sure that dependencies are properly checked and fixed.
Since introducing this into a project I work on, we managed to easily keep everything up-to-date across the mono-repo.
Try it out in your project! You’ll see that it makes your life way easier.

Keeping dependencies in sync in your mono-repo

The idea is simple; the user scrolls. As soon as the user is over a certain threshold, you snap to the next item. We used to do this with Javascript to calculate when the user is over this threshold. We would then manually scroll to a certain position with a neat animation.

Besides this code becoming complex, it relies heavily on Javascript (that needs to be loaded). Next to that, you'd need to take certain aspects into account like cancelling the scroll snap if the user changes scroll direction. It would be great if the browser can handle all of this for us. Luckily it can!
## CSS scroll snap
[The CSS scroll snap API](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Scroll_Snap) offers this for the web. In essence, you need two things. A container that needs to be scrolled in and items to snap to. Firstly, you add the `scroll-snap-type` property to the container:

```css
main {
  height: 100vh;
  overflow-y: auto;
  scroll-snap-type: y mandatory;
}
```

`y` is the direction you want to snap to. In this example, we want to snap while the user is scrolling vertically. `mandatory` is one of the values you can use to always snap:

*The visual viewport of this scroll container will rest on a snap point if it isn't currently scrolled. That means it snaps on that point when the scroll action finished, if possible. If content is added, moved, deleted or resized the scroll offset will be adjusted to maintain the resting on that snap point.*

Next, we can tell the items where we would like to align the scroll snapping to. You can do this by using the `scroll-snap-align` property on the item:

```css
section {
  scroll-snap-align: center;
}
```
And that's it! This is all we need to implement scroll snapping with CSS only. Have a look at the interactive demo over at [Codepen](https://codepen.io/davebitter/full/oNeJQJw) or below. Thanks for reading!
<p class="codepen" data-height="300" data-default-tab="result" data-slug-hash="oNeJQJw" data-user="davebitter" style="height: 300px; box-sizing: border-box; display: flex; align-items: center; justify-content: center; border: 2px solid; margin: 1em 0; padding: 1em;">
  <span>See the Pen <a href="https://codepen.io/davebitter/pen/oNeJQJw">
  Full-page scroll snap</a> by Dave Bitter (<a href="https://codepen.io/davebitter">@davebitter</a>)
  on <a href="https://codepen.io">CodePen</a>.</span>
</p> <script async src="https://cpwebassets.codepen.io/assets/embed/ei.js"></script> <script async src="https://cpwebassets.codepen.io/assets/embed/ei.js"></script>

Front-end

Articles

Smart cropping with native browser Face Detection

The infinite legacy cycle in front-end

Design handoff in the browser

Quick Bits

Keeping dependencies in sync in your mono-repo

Full page scroll snapping with CSS only