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

File is walked but then later removed and never re-walked #522

stffrd opened this issue Oct 12, 2018 · 1 comment


None yet
2 participants
Copy link

commented Oct 12, 2018

I'm currently running into an issue in @modular-css/svelte where a file of mine is being walked, but then removed due to having been seen in the processor in svelte/src/markup.js. It looks like the processor already contains my file, and as a result, the file (and its dependencies) are removed from the processor files cache.

Here's the code that gives me a problem:

 // Remove any files that've already been encountered, they should be re-processed
    if(external in processor.files) {
        [ ...processor.dependents(external), external ].forEach((file) => processor.remove(file));

... At what point do the files get re-processed? because it looks to me like each file is walked once, its dependencies all inspected on its walking, and then THAT'S IT. This looks like code that just nixes a file entirely if nothing else references it as a dependency?

My file situation is as follows:

  • we'll call the file this problem is occuring in file A
  • file A has a single :external selector reference to file B
  • file B has several :external selector references to a third, more shared file, file C

This doesn't seem too weird to me here, but I thought it was useful to include what the dep graph might look like.

In my various debugging attempts, I did a lot of in-module console logging.

  • I'm able to see file A get processed
  • Since file B is a dependency, I see file B get processed.
  • At some point, the code above in markup.js is hit, and the processor contains file A, so file A and its dependency file B are removed
  • Later on, file B is walked and included in the processor again (probably just as a top level glob walk)
  • file A is never added to the processor again and never makes it to the output.
  • I receive a Node does not exist error.

Here's a stacktrace:

[!] (@modular-css/rollup plugin) Error: Node does not exist: ...\a.css
Error: Node does not exist: ...\a.css
    at DepGraph.dependenciesOf (...\node_modules\dependency-graph\lib\dep_graph.js:187:13)
    at Processor.dependencies (...\node_modules\@modular-css\processor\processor.js:204:32)
    at css.forEach (...\node_modules\@modular-css\rollup\rollup.js:150:38)
    at Array.forEach (<anonymous>)
    at Object.entries.forEach (...\node_modules\@modular-css\rollup\rollup.js:148:21)
    at Array.forEach (<anonymous>)
    at Object.generateBundle (...\node_modules\@modular-css\rollup\rollup.js:136:37)
    at ...\node_modules\rollup\dist\rollup.js:20853:25
    at <anonymous>

If I comment out the removal code, this error goes away and things seem to work as intended, but I'm not 100% sure what the side effects are of eliminating that chunk of code happen to be.

Let me know if you need any more information!

@tivac tivac self-assigned this Oct 12, 2018


This comment has been minimized.

Copy link

commented Oct 12, 2018

That functionality was added in #463 as a fix for #462 , but I have no further information about where the need for this came from.

I think a better approach would be to not remove files by default, and instead only remove them if you pass a clean option or something. Seems like it would let both use-cases coexist peacefully w/o bothering each other?

@tivac tivac changed the title File is walked but then later removed and never re-walked (Svelte)? File is walked but then later removed and never re-walked Oct 13, 2018

tivac added a commit that referenced this issue Oct 15, 2018

tivac added a commit that referenced this issue Oct 22, 2018

feat: add "clean" option to svelte
Brings back the old behavior of dumping file + dependents if re-processing. Not sure it's necessary but that seems safer than fully removing atm.

See #522 for why the previous behavior wasn't ideal.

@tivac tivac closed this in a6e3ee6 Oct 22, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.