# 6. How does one test lerna packages at exile.watch: locally and in the real world

<figure><img src="https://1213438767-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F4DXEoZIzUdpt18CW2qTD%2Fuploads%2FzXjtfpnPjXaN7gAZDm9L%2Fexilewatch.webp?alt=media&#x26;token=74fc8000-b114-47be-bc13-cda9b75cd22f" alt="" width="256"><figcaption><p>exile.watch logo</p></figcaption></figure>

*This page is part of* [#the-toolkit-i-needed-to-make-it-all-happen](https://engineering.exile.watch/march-2024/lerna-the-hidden-powerhouse-of-exile.watch/..#the-toolkit-i-needed-to-make-it-all-happen "mention") *list - 6/7*

***

The final part explores how to effectively operate within this environment, focusing not only on local development but also on verifying the correct publication of prereleased packages.

As a starting point, I recommend reading [the-package-manager-of-exile.watch](https://engineering.exile.watch/march-2024/the-package-manager-of-exile.watch "mention") first. In it, I discuss package linking across all the package managers I evaluated, ultimately choosing npm as my go-to option.

## 1. [npm link and npm link @exile-watch/\<package>](https://docs.npmjs.com/cli/v8/commands/npm-link)

Utilizing `npm link` and `npm link @exile-watch/<package>` is the straightforward approach that works well most of the time—despite the occasional hiccup when symlinks go out of sync, which isn't a frequent issue and can be managed.&#x20;

I've detailed the challenges with this method in the previously mentioned post about package managers for those interested in digging deeper.

## 2. [yalc](https://github.com/wclr/yalc)

Yalc offers a solution akin to `npm link`, presenting a viable option for linking packages, though its success rate varies (see [#217](https://github.com/wclr/yalc/issues/217)).&#x20;

When it comes to integrating Yalc with Next.js, the reliability dips even further, as evidenced by mixed results (see [#188](https://github.com/wclr/yalc/issues/188) and the mirrored issue [#35110](https://github.com/vercel/next.js/issues/35110) on the Vercel repository).

A significant limitation emerges with chain linking.&#x20;

Why does this matter?&#x20;

Yalc falls short in resolving dependencies of dependencies (see [#95](https://github.com/wclr/yalc/issues/95)).&#x20;

For exile.watch, where each package serves as a comprehensive boilerplate focusing on distinct functionalities and configurations, this limitation complicates the testing process in consumer projects, making it a tedious task to ensure package compatibility.

## 3. [Preview publish](https://docs.exile.watch/projects/doryani/actions/preview-publish-package)

So, outside of using `npm link`, how do we test a package in its consumer environment?&#x20;

Enter our homebuilt automated prerelease system, which versions each release based on the commit hash.&#x20;

This method is as close as it gets to real-world testing.&#x20;

Why?&#x20;

Because it evaluates the package post-bundling, ensuring the changes behave as expected.

Occasionally, local modifications might not carry over after bundling, leading to errors from unsupported syntax (this is a skill issue of mine by sometimes being a dummy :))

[You can see it in action here](https://github.com/exile-watch/splinters/pull/17).\
\&#xNAN;*(I won't elaborate how this action works under the hood here as it deserves it's own post - for now here is the* [*sub-actions section*](https://docs.exile.watch/projects/doryani/actions/preview-publish-package#sub-actions) *which highlights what each step is responsible for*).&#x20;

***

*(WIP) Next on the line: Dependabot*

***

The links below won't redirect you to the initial page so here you have it for the conclusion of these parts:[#lerna-impact-on-exile.watch](https://engineering.exile.watch/march-2024/lerna-the-hidden-powerhouse-of-exile.watch/..#lerna-impact-on-exile.watch "mention")