When working on a dependency locally by linking it, Parcel 2 doesn't detect changes and therefore doesn't rebuild. You also need to remove the cache manually in order for it to work on re-runs.
Package.json
{
"name": "parcel-tamplate",
"version": "1.1.0",
"description": "My personal Parcel Template",
"main": "public/index.html",
"source": "src/index.html",
"author": "Samuel Elgozi <[email protected]>",
"license": "none",
"private": true,
"scripts": {
"dev": "parcel src/index.html",
"build": "parcel build src/index.html"
},
"targets": {
"main": {
"includeNodeModules": true
}
},
"devDependencies": {
"@babel/plugin-proposal-class-properties": "^7.8.3",
"babel-eslint": "^10.0.2",
"eslint": "^6.0.1",
"less": "^3.9.0",
"parcel": "^2.0.0-alpha.3.2"
},
"dependencies": {
"firebase-auth-lite": "^0.4.1"
}
}
The commands I use:
parcel src/index.html
Like in version 1, Parcel should detect changes in linked dependencies, invalidate the cache and rebuild.
No changes are made, which require manual removal of .parcel-cache and then building again.
I use Parcel to work on npm modules often. Without detecting the changes in linked packages there is no reason for me to use parcel. In fact, it becomes painful to do so...
| Software | Version(s) |
| ---------------- | ---------- |
| Parcel | 2.0.0-alpha.3.2 |
| Node | v13.10.1|
| Yarn |1.22.1
| Operating System | MacOs Catalina 10.15.3 |
Could you create a repo with some instructions on how I'd reproduce this? Would help a lot in fixing this
Ok, here you go: https://github.com/samuelgozi/Parcel2-issue-4332
Further instructions can be found in the repo's README file.
@samuelgozi thanks for creating the repo, I can reproduce it pretty consistently, will try and figure out why it happens and hopefully fix it
@DeMoorJasper Thank you!
I develop a local npm package and experience the same issue using the npm link functionality. Is there any news on this?
This is because the file watcher only watches for changes in the project root. It would be somewhat hard to implement support for symlinks outside the project I think. If we implemented this in the watcher we'd need to somehow crawl the whole file system to detect symlinks in the first place which would be very slow. We could potentially do it by detecting files that resolve to symlinks as we build the asset graph and keep nodes in the request graph to track watch roots. Then we'd have to re-watch all of those on startup and invalidate each of them for changes as opposed to just the project root.
Most helpful comment
@samuelgozi thanks for creating the repo, I can reproduce it pretty consistently, will try and figure out why it happens and hopefully fix it