• https://github.com/timoxley/pkgfiles
• https://github.com/thlorenz/irish-pub

Would be amazing to have a yalc watch script that automatically watches your package during development, and essentially runs a yalc push on changes.

My use case: Currently running yalc push manually when I have made a significant change that I want to test in my main application (where it is linked)

Potentially this just watches the whole package, or perhaps could specify a key file or folder to watch, eg: yalc watch src/index.js

What do you think?

I'm under the impression that yalc allows local access of local repos, yes?

When I do a 'yalc publish' in a local copy of a repo, it does a 'git push && git push --tags', neither of which I want to happen.

Running yalc add my-package adds "devDependencies": {} to a package.json that didn't have that key before.

(for context: we have a test that verifies that our package.json is free of devDependencies)

PS: ❤️ Thanks for building yalc!

Hi,

First och all thank you for this solution. I've been trying to get npm/yarn link working but have come across to many issues when working with symlinked packages which have driven me nuts.

Now to my request, would it be possible to watch for any file changes in the added/linked package and publish it automatically so I don't have to manually run yalc publish --push? I tried reading the docs, so might have missed this.

Thanks again! :)

How can I link typescript submodule project. It cause error when I try to link them because their didn’t compiled project

Supposing I have a main project A which has a dependency on Project-B, which in turn has a dependency on Project-C. Both Project-B and Project-C are managed as yalc dependencies.

npm install throws an error such as:
Could not install from ".yalc/project-b/.yalc/project-c" as it does not contain a package.json file.

When installing the reference to project-c, the project-b .yalc folder is the same as usual file:.yalc/project-c- however, this is then attempting to reference the dependent project within the project copied to the .yalc folder, however, it should be referencing the yalc folder from the root of the .yalc in project-b instead.

Basically, if you have a project in your .yalc folder that references another project in the .yalc repository, then it will incorrectly assume the referenced project is at the same level, when it should be looking to the root yalc folder in the parent project (i.e. project-a/.yalc)

I have a folder in the package with license in the name. The folder is excluded when publishing.

This is not as much as an issue, but rather a note where to find the store on Windows, it's located in the %USER_PROFILE%\AppData\Local\Yalc\packages and not in ~\.yalc. This was the second time I've looked this up and thought is was time to make a note of this.

I sometimes switch between different node versions and I noticed yalc link fails with node 8 today.

(node:94815) UnhandledPromiseRejectionWarning: TypeError: Symbol.asyncIterator is not defined.
    at __asyncValues (/Users/USER/.npm/_npx/94815/lib/node_modules/yalc/src/sync-dir.js:38:38)
    at Object.<anonymous> (/Users/USER/.npm/_npx/94815/lib/node_modules/yalc/src/sync-dir.js:99:33)
    at step (/Users/USER/.npm/_npx/94815/lib/node_modules/yalc/src/sync-dir.js:32:23)
    at Object.next (/Users/USER/.npm/_npx/94815/lib/node_modules/yalc/src/sync-dir.js:13:53)
    at fulfilled (/Users/USER/.npm/_npx/94815/lib/node_modules/yalc/src/sync-dir.js:4:58)
    at <anonymous>
(node:94815) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)

I reckon it's caused by this line here: https://github.com/whitecolor/yalc/blob/master/src/sync-dir.ts#L56.

Adding ESNext.AsyncIterable to the tsconfig might do the trick 👍

Repo:
Create a test project (I called mine test-delete) with the following contents

• examples
  • example.js
• lib
  • examples
    • example.js
  • src
    • file.js
  • alwaysIgnored.txt
• src
  • file.js
• .npmignore ->

  examples/
  src/*
  alwaysIgnored.txt
  

• alwaysIgnored.txt
• package.json -> { "name": "@test/test-delete", "version": "0.0.1" }

Actual: get by running yalc publish, navigate to yalc working path (for me on win10 %localappdata%/Yalc/packages/@test/test-delete/0.0.1)

• lib
  • src
    • file.js
• package.json
• (note: also includes .npmignore and yalc.sig which is expected)

Expected: get by running npm pack, package has the following contents

• lib
  • examples
    • example.js
  • src
    • file.js
• package.json

I was expecting yalc publish to output the same file contents as npm pack but in the case of a directory defined in the .npmignore it does not (in this repo the examples/ directory). Looks like unlike as advertised in the .npmignore docs directories work differently than in .gitignore files.

It's merely a concern of having obsolete stuff in a local repository. I just like to keep stuff clean. I know I can simply go to the user profile directory and delete the package from there, but it's kinda annoying manual step :) Then, of course, there is an installations.json which should be manually edited, but it doesn't matter in the end.

Ideally, I can imagine that yalc unpublish would check for existing installation and list them if any of those still exists. If there are none, it's safe to remove the package. The --force argument could remove the package from all installations instead of having to manually remove it everywhere.

Thinking about it now, there is actually no command to find out where the package is installed, hmm. That alone is kinda useful before doing a push imo.

Thank you very much for Yalc either way, it's super helpful especially on Windows where symlinks can be rather weird. I am using it heavily for packages under development. It's amazingly simple way as other team members don't need to any concern with it when I commit .yalc directory. 🎉

If you use yalc add and later use yalc remove to clean up, instead of just restoring the consuming app's package.json back to normal and removing the .yalc dir from the consuming app, it also removes a the corresponding package from node_modules.

Expected behavior

When using yalc remove after doing a yalc add, it shouldn't be touching anything in the consuming app's node_modules at all. It should just restore the changes it made to package.json and remove the files it added to .yalc.

Hi,

It would be nice to have a yalc unlink command.

I am forced to remove the symbolic link manually before re-install when I want to unlink a package, it's not very practical.

Anyway, thanks 🙏 for this amazing module ❤️ , it saved my life 🤣

It took me a while to figure out why one of my file named historyFetcher.js was not copied by yalk.

It turns out yalc exclude standard non-code files but do it with a broad brush:

var npmFilesIncludedByDefault = [
    'CHANGELOG*',
    'README*',
    'CHANGES*',
    'HISTORY*',
    'LICENSE*',
    'LICENCE*',
    'NOTICE*'
];

Any file starting with one of these keywords won't be included by yarn.

Hey, I like Yalc so much I just had to write an article about it. Would love to hear some feedback before it hits the public :)

https://medium.com/@DanielKrejci/modularize-a-shared-code-with-yalc-6f32031b647f

Is my understanding correct that running just the yalc commands as documented won't address various issues with yarn link, such as not installing transitive dependencies and not installing new/renamed bin scripts? (It's reasons like these that were our main motivation for looking into yalc in the first place.)

I spent some time experimenting, and it seems that running rm -rf node_modules/; yarn install afterward does patch up these issues. Just wanted to check that my mental model of how yalc/yarn are supposed to be used is correct, since this smells...non-ideal. (Running yarn install doesn't seem to do anything since it just does a quick "Resolving..." scan and reports "success Already up-to-date.")

If this is the case, then it may be worth at least mentioning in the documentation (where there's the NB about "but it doesn't execute yarn/npm install/update commands after this"). Thanks!

yalc.lock entry:

    "@what/ever": {
      "signature": "012344568987987",
      "file": true,
      "pure": false
    },

Will be replaced with "pure": true when @what/ever is yalc push because of the line:
https://github.com/whitecolor/yalc/blob/30d0cc7c933c41b71e578244b07538acae1085d6/src/update.ts#L54

Does not respect yalc.lock configuration at all, but unpreventably forces the --pure default via subsequent:

https://github.com/whitecolor/yalc/blob/30d0cc7c933c41b71e578244b07538acae1085d6/src/add.ts#L116

Says to use --no-pure, but --no-pure can't be given to yalc push, and earlier yalc add --no-pure is not respected.

it seems that yalc cannot work with pure npm, if i do yalc publish it fails with /bin/sh: yarn: command not found

So I've got a files section like:

  "files": [
    "dist/"
  ],

But when I run yalc publish the resulting directory never includes the "dist" directory.

Hi!

I have a dependency with an executable file (like this one). I get a permissions error when I run it. I manually run chmod +x and everything goes fine. Maybe you can include that in the process.

Thanks!

The prepublish script behavior has been deprecated in NPM since v1.1.71 and replaced with prepare. For better interoperability between yalc and npm/yarn, I think yalc's publish command should run the prepare script as well as or instead of prepublish.

I have three libraries (of about five that I am working on), where A depends on B which depends on C. Because the .yalc folder is not copied across when you do a "yalc publish", it means that yarn is not able to resolve C (as it is referred to as file:./.yalc/C in B's package.json).

Is there something I am missing about getting the .yalc folder copied? I am doing it manually at the moment to resolve it.

(this package is still awesome by the way)

After using yalc link I used yalc remove to tell Yalc to clean up after itself. However it leaves a link behind in the consuming app's node_modules folder. That link has to be removed manually before you can run yarn install --check-files to switch back to using the NPM version of the module you were testing.

At the very least I'd expect that yalc remove would completely clean up after itself so that you don't have the manually remove the link. Bonus points would be awarded if running yalc remove also restored the NPM version of the module.

Really excited to see this project because development has been a serious pain point with Workspaces. Would like to jump in right away and start using it and am curious how feature complete this project is. For instance, are people using this with Workspaces? In their own projects?

I know it's in pre-stage, but working with links in Workspaces and Lerna has been challenging so a buggy-but-working yalc would still be really nice.

Edit: Also, FWIW, it might be useful to describe this approach as a "Flux" unidirectional architecture for local dependency management. This might resonate with the React/front-end crowd. Rather than children tracking the state of other children, all changes are committed to a parent (the local registry) and the parent then pushes the data down to the children. As far as I can tell, this is a flux architecture for dependency management and solves the same general problem that React solved

I have 3 repos which I publish as separate packages. Let's call them pkgA, pkgB, pkgC.

Steps to replicate:

1. Run yalc publish on pkgA
2. Run yalc add pkgC from pkgB
3. Run yalc publish on pkgB
4. Run yalc add pkgB from pkgA
5. Run yarn from pkgA -> Error - it's looking for pkgC in the wrong yalc directory.

Please help! Thanks!!

Hi there!

This is a great repo and it makes our workflow so much easier! So thanks for that...

I was wondering if there is an option to 'unpublish' packages once they are published. The reason I am asking is because of a situation like this:

• Repo A is a component to be yalced and it will be used by few projects. So this repo is yalc published.

• Project A and project B both are using the repo A. So they have yalc added repo A.

• Later on Project B was deleted from the file system.

And now, when you try to yalc push the repo A, it gives a warning that it can't find the package.json of the Project B (since it is deleted). It works without problems with the Project A symlink.

Since project B is deleted I cannot do a yalc remove from that directory. Is there a way to remove this link from the repo A's side?

I hope I managed to explain the problem. Happy to provide more information if required.

Thank you for the great work! Cheers!

I realize that this is still in development, but I'm excited about the possibility of this tool greatly improving my team's workflow. Ran into this error when giving it a spin, though.

~/dependency ᐅ yalc publish
/bin/sh: yarn.lock: command not found
(node:67368) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 1): Error: Command failed: yarn.lock
/bin/sh: yarn.lock: command not found

Looks like the error could be on this line? https://github.com/whitecolor/yalc/blob/master/src/index.ts#L93
And if that's it, https://nodejs.org/api/fs.html#fs_fs_existssync_path might be helpful.

yalc version 1.0.0-pre.5
yarn version 0.23.2
node version 6.9.4
os x version 10.11.6

yalc push -i would prompt the user for each dependent package. Then the user could choose explicitly which packages to push to.

It looks like a new version was released 4 days ago [1], but there's no way to check if a currently-installed version is up-to-date without figuring out where it's installed and checking its package.json:

$ yalc --version
Use `yalc help` to see available commands.

$ yalc version
Unknown commmand `version`. Use `yalc help` to see available commands.

$ yalc help | grep -i version || echo "no version"
no version

[1] To NPM, but not (yet?) in Git. Please consider adding and pushing tags for these so they show up here.

How to use yalc if a local dependency using a yarn workspace? For example

local dependecy:

package.json
packages:
  moduleOne
  moduleTwo

How do you require moduleTwo with yalc?

I used yalc publish and yalc add. The module is showing up in package.json, but project still cannot resolve the module. What are some trouble shooting steps I can take?

Both yarn and npm will search for a package.json in parent directories if not found in the cwd. Yalc should follow this same practice.

Say I'm in myproject/src, yarn build will execute fine but yalc push will throw Could not read myproject/src/package.json.

I would like to start a script that watches local dependencies and incrementally update corresponding content of .yalc folder.

Make sense? How do you do it now? Call yalc publish --push on each change?

we store our consistent typescript versions along with test dependencies in one package, and being able to yalc add/publish them as they are updated (via dev dependencies) would be very useful.

I am working around it by just adding and then moving the dep.

(thank you for addressing this glaring problem with "link")

I have 2 packages that I am trying to link into a project. For both of them, when I run yalc publish --files it's only publishing 3 files in the package: index.js, package.json, and README.md. All other files are being ignored.

Hi,

Is there a yarn --cwd equivalent in yalc? So that one does not have to cd.

Thanks!

This might be somewhat niche, but my company uses Perforce which automatically (and annoyingly) sets all files with the permission to 444. pre.29 after 543d26d fails with:

(node:56902) UnhandledPromiseRejectionWarning: Error: EACCES: permission denied, open '/Users/USER/.yalc/packages/yalcc/1.0.0/index.js'
(node:56902) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)
(node:56902) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

Can there be a flag on the publish command that allows us to do an unsafe copy? I'm happy to make a PR. LMK 👍

Repro

Here's a small shell script to test it out:

mkdir sample && cd sample
npm init -y
echo "module.exports = {};" > index.js
chmod 444 index.js
npx yalc publish

The use case is I want to test the install script in package without publishing it remotely. However when I run yalc then yalc add it packs all fine except the permissions are not retained.

before

-rwxr-xr-x    1 van  staff    1126 Apr 17 23:42 sync.js

after

-rw-r--r--   1 van  staff    1126 Apr 17 23:44 sync.js

As you can see the execute permissions has been stripped, therefore I cannot execute my script as it's meant to.

When I run yarn install --force

It gives me this error

/bin/sh: ./sync.js: Permission denied

I've only recently switched to using yalc over yarn link and it's been super useful for fixing issues such as duplicate deps etc. Through my use over the last couple of days I've noticed that every time I link a package I'm working on to another project it does not install it's deps. Say I have a package with some deps of it's own and run yalc add <package_name>, I have to immediately run yarn to get it's deps to appear in my project. I feel like the yalc add command was purposefully designed to mimic the experience of yarn add thus I feel the correct behaviour after running yalc add <package_name> would be for it to run yarn or npm afterward.

Problem

When running a watch script in a package consuming another local package that has been marked as a local dependency using yalc. When yalc push is called in the consumed package an error occurs and the watch script breaks in the consuming package.

Example of the error:

D:\repos\test-delete> yalc push
Pushing @test/[email protected] in D:\repos\test-delete-watcher
(node:31748) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 1): Error: EPERM: operation not permitted, lstat 'D:\repos\test-delete-watcher\.yalc\@test\test-delete\lib\index.js'
(node:31748) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

Repo

Create two projects with the following files/contents
test-delete

• lib
  • index.js
• package.json

  {
      "name": "@test/test-delete",
      "version": "0.0.1",
      "main": "lib/index.js"
  }  
  

test-delete-watcher

• src
  • index.js

    require('@test/test-delete');
    

• package.json

  {
    "name": "@test/test-delete-watcher",
    "version": "0.0.0",
    "scripts": {
      "bundle": "webpack",
      "watch": "webpack --watch"
    },
    "dependencies": {
      "@test/test-delete": "file:../test-delete"
    },
    "devDependencies": {
      "webpack": "4.17.1",
      "webpack-command": "0.4.1"
    }
  }
  

in test-delete-watcher run yarn install (to get the webpack dependencies so that yarn run bundle and yarn run watch will work)

in test-delete run yalc publish

in test-delete-watcher run yalc add @test/test-delete

in test-delete-watcher run yarn run watch to start bundling and watching for changes

in test-delete run yalc push

See the failure above
Also in test-delete-watcher/node_modules/@test/test-delete the src/index.js file is now missing

To get the system to work again have to run yalc push in test-delete and restart the watch in test-delete-watcher

System info

64-bit windows 10

Yalc is ignoring subdirectories matching "standard non-code files" such as lib/history/**

The workaround listed in the README (adding an explicit include to .npmignore such as !history or !**/history or !lib/history) does not work for subdirectories because of how the ignore() function works

@whitecolor can you provide some context on why should the standard non-code globs be ignored in any case? It seems more consistent to me to include all files that npm pack would have included.

I've provided a PR which limits the standard non-code globs to the root of the package, but in my opinion, I'd rather see the blacklist removed.

Inside my project I've got a package.json file that has been configured for npm publish to only publish selected files:

...
  "files": [
    "build",
    "yarn.lock"
  ],
...

Unfortunately, I lost work that I had in my git stash when I then executed yalc publish and everything but those specified paths was deleted including .git.

I've got a files section like:

"files": [
    "dist/",
   ".yalc/"
  ],

But no folder exists when I publish.

Hi,

I was wondering if this works with add a breakpoint to my library/module.

So the scenario would my main application has a library added using yalc (using the link i presume) and i attached a debugger to my main nodejs application.

I also add a breakpoint to my library - would it stop ?

It is technically publishing this to a different location - right ?

Is there any way this can work with debugging / breakpoints ?

I would like to use this with typescript and I will be using ts-node

Let's say I have two packages A and B. B depends on A. I use yalc to add A to B, will yalc resolve A's dependencies into B's node_modules folder (as if I npm installed A)?

When using the link command the documentation states that it will not touch package.json and is similar to npm/yarn link. This behavior is not preserved for subsequent uses of yalc update and yalc push and the package.json is updated to include link: dependencies.

The package.json usually has a newline at the end of the file.

When it's changed by yalc, the newline is gone, which produces an unnecessary change.

This shouldn't happen.

Hey,

I've added a package (which is a sub-package in a folder) with following command: yalc add --link project-x.

Now my package json reads correctly:

dependencies: {
  "project-x": "link:./yalc/project-x"
}

But after yalc push project-x from my parent folder of project-x, my package.json looks like:

dependencies: {
  "project-x": "file:./yalc/project-x"
}

Did I miss something here?

Can one use yalc without modifying package.json?

We're working on a codebase where most users should not need local checkouts of the dependencies, so in package.json we specify git repos for these dependencies. When we do need to locally iterate on the dependencies, we use yarn link, but we're interested in adopting yalc to address the issues with yarn link. But since most users should continue to pull dependencies from the git repos rather than a yalc store, we don't want to actually modify package.json.