Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

parcel 2 doesn't notice files changed in modules included via file: ../something and caches them until the cache is removed #5628

Closed
danieltroger opened this issue Jan 12, 2021 · 9 comments

Comments

@danieltroger
Copy link
Contributor

🐛 bug report

clear cache for fresh start

daniel@iMac:/tmp/pbr/repro_main$ rm -rf .cache .parcel-cache/ dist

run serve

daniel@iMac:/tmp/pbr/repro_main$ npm run serve

> serve
> parcel serve --port 1234 src/main.ts

ℹ️ Server running at http://localhost:1234
✨ Built in 436ms

check consistency of input / output

daniel@iMac:/tmp/pbr/repro_main$ grep alert dist/main.js
exports.default = () => alert("YOOOOOOOOOOOOOO");
daniel@iMac:/tmp/pbr/repro_main$ grep alert ../mymodule/file.js 
export default () => alert("YOOOOOOOOOOOOOO");

npm run serve has built evereything as expected.

Now edit ../mymodule/file.js and change the string inside alert. I have changed it to I'M HIDING FROM PARCEL

Run npm run serve again or just keep it running, it doesn't matter

daniel@iMac:/tmp/pbr/repro_main$ npm run serve

> serve
> parcel serve --port 1234 src/main.ts

ℹ️ Server running at http://localhost:1234
✨ Built in 74ms

check output for consistency

daniel@iMac:/tmp/pbr/repro_main$ grep alert ../mymodule/file.js 
export default () => alert("I'M HIDING FROM PARCEL");
daniel@iMac:/tmp/pbr/repro_main$ grep alert dist/main.js
exports.default = () => alert("YOOOOOOOOOOOOOO");

Parcel cached where it shouldn't. The output does not show what it should.

This has probably cost me soon 20 minutes of debugging in vain because I fell for it multiple times.

Same result running it again:

daniel@iMac:/tmp/pbr/repro_main$ npm run serve

> serve
> parcel serve --port 1234 src/main.ts

ℹ️ Server running at http://localhost:1234
✨ Built in 74ms
daniel@iMac:/tmp/pbr/repro_main$ grep alert dist/main.js
exports.default = () => alert("YOOOOOOOOOOOOOO");
daniel@iMac:/tmp/pbr/repro_main$ 

The only way to unstuck it is to remove .parcel-cache

🎛 Configuration (.babelrc, package.json, cli command)

Sorry, you will need to check the attached reproduction repo

Worthy excerpt:

"dependencies": {
   [...]
    "mymodule": "file:../mymodule"
  }

🤔 Expected Behavior

The output code should update when the input code changes

😯 Current Behavior

It does not update

💁 Possible Solution

Update the output when the input changes, even in modules included via ...

🔦 Context

I have a "lib" directory which I include as module and I always wonder why I am stupid when I change code in there but my issues still persist.

💻 Code Sample

parcel-cache-bug.zip

🌍 Your Environment

Software Version(s)
Parcel 2.0.0-nightly.524+97a7bfee
Node v15.5.1
npm/Yarn npm v7.3.0
Operating System macOS 10.13.6
@mischnic
Copy link
Member

mischnic commented Jan 12, 2021

Symlinked folders outside the root aren't watched: #4950

And I didn't know file: means creating a symlink with npm and copying the folder with Yarn. link: creates a symlink with Yarn but npm throws an error.

@devongovett
Copy link
Member

Parcel doesn't watch files outside the project root. I guess ../mymodule fits that case?

@danieltroger
Copy link
Contributor Author

Oh shoot, sorry for the duplicate issue then. I didn't know either it just symlinked.

But what speaks against just resolving the symlinks and treating them as relative paths? You did that to fix the module duplication issue when running build, so why not for serve too?

@danieltroger
Copy link
Contributor Author

Another tiny bug I found: if you rename the module to my_module everywhere and remove its package.json the underscore will not show up in the error message but make the text italic

@mischnic
Copy link
Member

error message but make the text italic

-> #4057

But what speaks against just resolving the symlinks and treating them as relative paths?

https://github.com/parcel-bundler/watcher/ has to start at some directory which is watched for changes recursively. And no OS resolves symlinks in that process (what you described).

@danieltroger
Copy link
Contributor Author

I see, thanks for explaining. Why does it need to watch a directory? Parcel should know all files it includes (it prints them when building with --detailed-report) it could then resolve their real location and just watch the included files?

@mischnic
Copy link
Member

  1. There are limits to how many individual files can be watched
  2. What about files that don't exist yet? These can't be watched (e.g. adding a config file).

@danieltroger
Copy link
Contributor Author

To 1: Then resolve the file's location and watch the parent directory
To 2: Config files can only be in the directory of package.json, right? So when package.json is read and it's directory added to the stack of directories to watch it should detect configuration changes

Also as a side note, if you're saying it watches directories that makes me curios what would happen if a file would be on a strange filesystem like sshfs inside of a large folder where the OS doesn't load the contents when only a single file is accessed.

@mischnic
Copy link
Member

mischnic commented Jan 12, 2021

  1. That's what's we're probably going to do: Parcel does not watch/refresh changes inside a symlink folder #4950 (comment)

Config files can only be in the directory of package.json, right

No

  1. There are a few strategies listed for watching the filesystem, they are, as I've said, provided by the OS, so I'm not sure how Linux handles a sshfs in this case. Here's a list: https://github.com/parcel-bundler/watcher.

Anyway, this is a duplicate of #4950.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants