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
improve addon-dev clean #1855
base: main
Are you sure you want to change the base?
improve addon-dev clean #1855
Conversation
aa83374
to
3883ada
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Logically, it seems good.
Do we have any tests for this behavior? I don't remember: 😅
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
so one thing that I would like to do before we actually move forward on this is that we verify that this Plugin works correctly with the bug scenario that #1448 was originally trying to fix. Ideally we would cover this in the v2 addon dev watch tests
I think what this actually does now is more like a I think this also fixes the original issue. As long as files are copied as part of the bundle, by e.g emit, and not using manual copy. This will work correctly. |
can we add a test? I could not reproduce the issue that caused the need for this
The problem I have with this PR is that I want more confidence that it fixes the original issue before we move forward with it. Myself and @NullVoxPopuli tried to recreate the issue on the Triage meeting and we couldn't get it to fail so we can't tell if this makes any difference 🙃 I would really like a failing test that shows the problem in a repeatable way before we try to fix it by altering the underlying implementation. If this is not possible (because maybe it's an OS level race condition 🤷) then at the very least we need to coordinate with @simonihmig because he said he would be looking into the original issue over the next while: embroider-build/addon-blueprint#32 (comment) |
I'm not sure how to add a test for this |
@mansona i improved this even more and added some tests |
94f3ccb
to
f472a50
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tested this locally with a real project and yarn link
. I found some minor issues, see inline comments. But the good part is that this seems to also fix some of the issues discussed in embroider-build/addon-blueprint#32 (comment).
The main issue I was hoping to get fixed by a revised clean plugin was the fact that an app watching the dist folder of an addon would often pick up changes as they were written but before the addon's rebuild has finished.
Leading to multiple app rebuilds, with the first ones often picking up interim build errors. Which would quickly go away, when the addon's rebuild has finished, but that's still annoying...
And testing this change here locally indeed seems to fix that issue! 🎉
@@ -14,11 +13,10 @@ export default function rollupGjsPlugin( | |||
return { | |||
name: PLUGIN_NAME, | |||
|
|||
load(id: string) { | |||
transform(input: string, id: string) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This change and the one on the hbs plugin are unrelated to the actual scope of the PR, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's required to have hbs pass through transform to have thrm incremental.
addon.publicEntrypoints(['components/**/*.js']), | ||
addon.appReexports(['components/**/*.js']), | ||
addon.publicEntrypoints(['components/**/*.{gts,js}']), | ||
addon.appReexports(['components/**/*.{gts,js}']), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are these changes needed? IIRC, the inputs to these plugin were meant to relate to the final output, which is always .js.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, maybe it wasn't needed
}, | ||
generateBundle(options, bundle) { | ||
if (existsSync(options.dir!)) { | ||
const files = walkSync(options.dir!, { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
any concerns about this file walking being potentially too expensive to do on every rebuild?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's required to delete files that are not part of the bundle. We could also do this with diffing between builds and only do a walkSync at start.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I improved this ti only walk once
for (const file of files) { | ||
if (!bundle[file]) { | ||
generatedAssets.delete(file); | ||
rmSync(join(options.dir!, file)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it seems watchChange
provides us the information what files have changed or were deleted. Could we track these events and apply the syncing based on those, instead of the file diffing here?
Does that make any sense even? Not saying this is better or might not even work, just curious...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
generated assets with emitfile do not pass through transform/watchchange. So it's not detectable
// rollup already supports incremental transforms of files, | ||
// this extends it to the dist files | ||
clean() { | ||
return clean(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we consider this a breaking change? If not, this PR could target the stable branch, not?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we consider this breaking, we could still release this on stable as a minor version, by exposing this as a separate plugin, and updating the blueprint to use the new one instead of addon.clean()
! 🤔
this only cleans up deleted files. otherwise all files are deleted everytime, which makes HMR less useful
f130369
to
00ed454
Compare
this now only updates changed files in dist. And deletes removed files in dist.
otherwise all files are deleted on each change, which makes HMR less useful