npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

@jensbodal/lndir

v0.2.1

Published

Symlink specific directories within an npm package

Downloads

3

Readme

lndir

Facilitates creating symlinks for directories within an npm package rather than having to symlink the package's root folder

Problem

yarn link and npm link are not flexible and only allow symlinking the root folder for a package. This results in a link to the node_modules package within the library's folder, which may or may not contain dev only packages which are irrelevant to the runtime of the library, and can cause dependency issues if those dev only dependencies are picked up instead of your package's dependencies. The same is true and more likely for packages declared as peerDependencies.

Solution

Install the package normally. Then symlink your locally installed version's runtime to the installed location's.

Caveats

If you are adding new libraries in the library that you are trying to link, those libraries won't be present in the linked folder. You'll want to install those locally to use them. You could also try installing the package using the file:// syntax and then symlinking from there.

This might not work for packages that do not produce a single folder for which the runtime is to be executed from. For example some packages will publish folders to the root of their package's folder at publish time in order to present a clean folder structure and/or to allow importing from submodules.

While you can simply use the root folder for the symlink, this will then symlink the node_modules folder in that locally installed package as well. If there are peerDependencies or devDependencies that conflict with your consumer package's modules, there could be issues.

Possibly in a future release this package can symlink all folders within a folder except for exclusions.

Usage

Link your locally installed version of a package

Assume we have a package with a published name (the name specified in its package.json file) of @foo/bar.

We want to make changes in this package and see them in another package which consumes this package.

ln dist

/**
 * package is now available at:
 * {
 *   "@foo/bar": {
 *     "absolutePath": "/some-path/bar/dist"
 *     "linkedPath": "dist"
 *   }
 * }
 */

Use a locally linked version of a package

ln @foo/bar