-
Notifications
You must be signed in to change notification settings - Fork 143
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
Fix synthesized template-only components crash #1620
Fix synthesized template-only components crash #1620
Conversation
|
|
Thanks for the fix 🎉 you inspired me and @NullVoxPopuli to pair on finally implementing app-level watch-mode tests in #1624 It would be super awesome if we could demonstrate your fix by having a failing test that then starts to pass with your PR, what do you think? |
That would be great! |
@chancancode we finally ironed out the issues with #1624 (I'm done with windows 😭) so you can create the watch mode tests now 👍 Let me know if you have any questions about the setup 👍 |
These tests are currently written to exhibit the buggy behavior. When I fix the issue I'll adjust the tests to the correct/expected behavior.
This fixes the first scenario detailed in embroider-build#1619, where a synthesized template-only component .js file is not cleaned up when the corresponding .hbs file is deleted. There are actually two bugs here. The first issue is we never attempt to clean up these unneeded files, which is fixed by keeping track of which of the emitted files are still needed after the main loop. The second issue is that, even with that fix, it still does not work, because we are incorrectly using the async version of the fs API here without awaiting for the promise. With the way the promisify code is written, the fs delete is actually scheduled to happen on the microtask queue, so by the time the `mergeTrees` code runs, the deletion hasn't actually happened yet. Since the synthesized tree appears after the appTree, I believe (but haven't tested) this has also been causing a different bug, where if you started with just a `.hbs` file, then add a `.js` file later, the new file does not actually take effect until one more build later, since the build triggered by the `.js` file creation would get shadowed by the previously synthesized template-only component file. Perhaps no caught this issue because the typical workflow involves creating either an empty file or generating a stub `.js` file, then filling it in with the actual content. By the "first meaningful save", the deletion would probably have gone through and this would self-resolve.
As discussed in embroider-build#1619, tools like babel caches the ouput based on the source content of the input files. For component javascript files, whether there is a co-located template file is an extra bit of information that doesn't show up in the source file, but that information does get used in producing the output. This causes the caches to not invalidate when a co-located tempalte file is added or deleted. This fixes the problem by ensuring we include that information in the input source file. For now, it is just an inert comment, but we can actually adjust our babel plugin to rely on this information rather than doing its own filesystem probing again, which should have some performance benefit.
a390c25
to
fdf7d4c
Compare
Oops I accidentally pushed everything to #1632 so I’ll just close this |
This fixes
the first scenario detailed in#1619. See the individual commit messages for details.