-
Notifications
You must be signed in to change notification settings - Fork 137
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
addon-dev: incremental updates to output #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! 🎉
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()
! 🤔
f130369
to
00ed454
Compare
9dd0b3a
to
a13adec
Compare
0106e1e
to
3b98560
Compare
tests/scenarios/v2-addon-dev-test.ts
Outdated
@@ -73,6 +73,8 @@ appScenarios | |||
exclude: ['**/-excluded/**/*'], | |||
}), | |||
|
|||
addon.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.
Is this change in order required? If so, then this is clearly a breaking change!
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 think it is. I need to revalidate
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 news on this @patricklx?
With ~250 addons in our monorepo (not all v2 though), I'd rather not have to write a codemod to change the order! 😏
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.
hi @simonihmig I reverted the change and the tests passed. (other unrelated failed)
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.
hold that, i forgot one, lets see
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.
There was a timeout in one test job. I restarted and it is all green now! 🎉
Thanks for getting back to this, I think this revert is helpful, as it shows we are not introducing breaking changes here!
I have faced the ENOENT error for the addon.clean() which triggers file deletion event while rollup watch but it is not build stopping issue just error thrown and started build once dist was replaced. After @NullVoxPopuli suggestion to try this addon-dev branch now ENOENT error resolved. But the below warning is shown but is harmless I guess... |
@@ -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.
@ef4 I noticed that now the gjs plugin must come before the babel plugin in the rollup config. That would make this a breaking change
@@ -12,6 +12,10 @@ export default function rollupHbsPlugin({ | |||
return { | |||
name: 'rollup-hbs-plugin', | |||
async resolveId(source: string, importer: string | undefined, options) { | |||
let hbsFilename = source.replace(/\.\w{1,3}$/, '') + '.hbs'; | |||
if (hbsFilename !== source) { | |||
this.addWatchFile(hbsFilename); |
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.
@ef4 I had to add addWatchFile to all 3 methods to get this to work correctly on windows
This is hard for me to follow. Can we take advantage of the cleanup that has happened in the vite hbs plugin to use the same patterns here? |
f7fc9e2
to
b64444a
Compare
I updated the hbs plugin to be similar to the one in vite hbs. also added the addWatchFile calls to get tests working |
} | ||
} | ||
|
||
let syntheticId = needsSyntheticComponentJS(source, resolution.id); |
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.
we do not have a packageCache here
2bea12d
to
1b9fcf1
Compare
@@ -63,6 +63,7 @@ export default function rollupHbsPlugin({ | |||
let syntheticId = needsSyntheticComponentJS(source, resolution.id); | |||
if (syntheticId) { | |||
this.addWatchFile(source); | |||
this.addWatchFile(syntheticId); |
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 did not work @ef4 .
I think transform does have its own specific cache.
https://rollupjs.org/plugin-development/#transform
d0d446c
to
b755ba2
Compare
let syntheticId = needsSyntheticComponentJS(source, resolution.id, resolverLoader.resolver.packageCache); | ||
if (syntheticId) { | ||
let syntheticId = needsSyntheticComponentJS(source, resolution.id); | ||
if (syntheticId && isInComponents(resolution.id, resolverLoader.resolver.packageCache)) { |
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.
@ef4 is this okay like this?
b755ba2
to
1467bde
Compare
41f2cd6
to
2cb99d7
Compare
2cb99d7
to
afb4998
Compare
afb4998
to
84c96d0
Compare
…-to-output backport #1855 addon-dev: incremental updates to output
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