Codecov Report

Merging #4376 (0e1b321) into master (f420a01) will decrease coverage by 0.00%.
The diff coverage is 83.33%.

@@            Coverage Diff             @@
##           master    #4376      +/-   ##
==========================================
- Coverage   98.72%   98.72%   -0.01%     
==========================================
  Files         205      204       -1     
  Lines        7320     7315       -5     
  Branches     2083     2082       -1     
==========================================
- Hits         7227     7222       -5     
  Misses         34       34              
  Partials       59       59              

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f420a01...0e1b321. Read the comment docs.

do you think it would make sense to drop those in a Set, and only create it once for sure? might improve perf.

Yes, but I think there are some things to consider:

• Such Sets should be reset per-build (e.g. in watch mode), because directories could be removed again (e.g. there might be a plugin clearing the output folder before every build, therefore all directories should be recreated per build. Or directories are removed manually)
• It would make sense to cache a lot more stuff per build. One thing that REALLY costs performance in my observation is using path.resolve. It seems to me that this method might actually be doing synchronous blocking file system IO to e.g. resolve symlinks. That is why using node-resolve is actually faster than vanilla JS: Because it is caching directory reads and doing all directory resolution manually via https://www.npmjs.com/package/resolve, which actually comes from browserify. I would not use that package in rollup core, though, instead I wonder if Rollup should not provide its own abstraction over the file system that uses a cache that is reset for each build. If that is made available to plugins, we could make many plugins browser/Deno compatible/independent of the runtime while making everything faster. And no longer have node-resolve rely on resolve.

Now the second point is independent of the first, but it makes we wonder in how far we want to think about a more general solution.

Yes, but I think there are some things to consider:

@lukastaegert didn't ignore this, I'll get back to you on that.