Share common code with yarn workspaces
Tags: npm, javascript, yarn, ember
Published: 2018-11-25 14:48:49

---
title: Share common code with yarn workspaces
published: true
description: Reusable components are an awesome concept but how does one develop them and use them at the same time in a way that scales?
tags: npm, JavaScript, yarn, EmberJS
---

The basics of *yarn workspaces* is very well [described in the official yarn documentation](https://yarnpkg.com/lang/en/docs/workspaces/) or [other blog posts](https://medium.com/square-corner-blog/ember-and-yarn-workspaces-fca69dc5d44a). The way I use it in my project is:

 - My project lives as a [monorepo](https://en.wikipedia.org/wiki/Monorepo).
 - My project uses [EmberJS](https://www.emberjs.com/), but I assume the things from this post applies to any npm-based project.
 - There is a *bp-ember-components* subdirectory that has the code that is shared across all the consuming apps.
 - There are multiple *apps* that consume mentioned *bp-ember-components*.

## Examples 

Omitting non-interesting parts. The `admin` package in top level `package.json` is just another consuming app, the same as `frontend`.

Top level `./package.json`:

```#json
{
  "name": "monorepo",
  "workspaces": {
    "packages": [
      "frontend",
      "admin",
      "bp-ember-components"
    ],
    "nohoist": [
      "**/semantic-ui-ember",
      "**/semantic-ui-ember/**"
    ]
  }
}
```

App level `./frontend/package.json`:

```#json
{
  "name": "frontend",
  "devDependencies": {
    "bp-ember-components": "0.0.0",
  }
}
```

## nohoist

The most important part for me is the [nohoist yarn option](https://yarnpkg.com/blog/2018/02/15/nohoist/). Originally I used [npm link](https://dev.to/michalbryxi/share-emberjs-common-code-between-apps-1a7k) to solve the same problem. Mainly because *yarn workspaces* were failing for me with random weird errors.

The *tl;dr* is: *Yarn workspaces* feature might install a package in different `node_modules` directory than the "standard one". And some packages access sources of other packages (or itself) assuming that those are installed in the "standard" directory. So then when you run your project, it will just fail miserably.

Solution? 

 1. Look into the stack trace of what has failed and try to identify the "root cause" package. Probably it will be something that is mentioned in one of your `package.json`.
 1. In the top level `package.json` add to `nohoist` array this *problematic-package* in the following way: `"nohoist": [ "**/problematic-package", "**/problematic-package/**"]`
 1. Remove `node_modules` directory in the top level and all the "subdirectories". Maybe not entirely necessary, but just to be sure.
 1. Now one of three things happens:
   1. If the error message changed, you probably hunted one down and can go back to step #1.
   2. If the error message did not change, then try to guess-pick another package and proceed with step #2.
   3. If the error message disappeared, then you just won this hide & seek game!
 1. Be a good citizen and [report the problem](https://github.com/Semantic-Org/Semantic-UI-Ember/issues/241) to the package maintainer. Maybe linking this article might help to explain what is wrong.