Open roryabraham opened 2 months ago
I was initially planning to add watch mode for publish mode but my build didn't delete files so it was sufficient for my needs.
Happy to accept a PR to add watch mode. But it should use Node's built-in watcher instead of pulling in a 3rd party dependency to keep install size small.
Ok, thanks for the feedback!
I was getting ready to submit a PR using chokidar (which I went to for its popularity and use in reputable libraries such as webpack).
However, I found that, because it includes native node modules, it's incompatible with https://github.com/privatenumber/pkgroll. So I was about to open a PR in that repo to add rollup-plugin-natives
so that it can bundle dependencies with native modules as well as JavaScript. I imagine that might be valuable independently, regardless of whether you want to proceed with Node's built-in watcher or chokidar.
Draft PR using chokidar: https://github.com/privatenumber/link/pull/23
PR to enable native node modules in pkgroll: https://github.com/privatenumber/pkgroll/pull/68
Draft PR using Node's built-in filesystem watcher: https://github.com/privatenumber/link/pull/24
Ok, both of these PRs seem to work. Personally I'd probably recommend chokidar for all the reasons listed in the package description, but if you want to keep it lean and use pure node, that's fine. That also means that https://github.com/privatenumber/pkgroll/pull/68 is not strictly required.
This is a great improvement @roryabraham and just what I would need to use this package. I wonder if this feature still requires some work since I see that PR is in draft state?
yeah, I haven't further pursued it since my first attempt. Frankly, I was working on fixing a bug in a React Native library, and dove into this to improve my development experience. But then someone else fixed the bug, and I haven't picked this back up.
From what I recall, the draft PR wasn't quite working yet. I had logs set up that would correctly observe when a file was deleted and a new hard link created. But then running ls -i
on the supposedly-relinked file revealed two different inodes, with the original (broken) inode still in use.
Feature request
One downside of hard links is that if a source file in your dependency is not changed but deleted and re-created by the build process, then the hard link is broken.
So the request I have is to either, set up a watch mode such that hard-links can be re-created if one of the source files disappears, or create an option to use symlinks with the
publish
option.Motivations
I noticed this because my changes appear correctly after running
npx link publish ~/react-native-live-markdown
, but if I change the source files then the hard-link is broken.So my situation is:
publish
(i.e: use symlinks), but then the file structure is different and doesn't work as expected in my apppublish
then the file structure is as expected and it works, but changes to the source code of my dependency break symlinks (and it would be very complex to try and change the build process such that it just updates files in place rather than deleting and re-creating them).Alternatives
not sure
Additional context
No response
Bugs are expected to be fixed by those affected by it
Compensating engineering work financially will speed up resolution