addon-shim is currently creating a broccoli tree based on the v2 addon's root folder, and funnelling that based on the entries in app-js/public-assets, and exposing these trees as treeForApp/treeForPublic for integration into a classic build.
The problem with this is that it will trigger a rebuild of the app when something changes outside of the folders where the actual files live in (like dist/_app_ for the app tree), most notably the ./src folder, causing the app watcher to fire multiple times in succession: once for the change in ./src, and later (when the rollup build has finished) for the change in ./dist.
The PR here optimizes this, by making the root folder that goes into the broccoli-funnel to be as close as possible to the actual files. So (assuming our opionionated v2 setup based on the blueprint), that would be /path/to/addon/dist/_app_ instead of /path/to/addon for the app tree, and same for the public tree.
I tested this in a local installation, and it did have the desired effect (when combined with the other PR): when changing only source files and not having the addon's build running in parallel, the app would not rebuild, as it would be expected.
addon-shim is currently creating a broccoli tree based on the v2 addon's root folder, and funnelling that based on the entries in app-js/public-assets, and exposing these trees as treeForApp/treeForPublic for integration into a classic build.
The problem with this is that it will trigger a rebuild of the app when something changes outside of the folders where the actual files live in (like
dist/_app_for the app tree), most notably the./srcfolder, causing the app watcher to fire multiple times in succession: once for the change in./src, and later (when the rollup build has finished) for the change in./dist.The PR here optimizes this, by making the root folder that goes into the broccoli-funnel to be as close as possible to the actual files. So (assuming our opionionated v2 setup based on the blueprint), that would be
/path/to/addon/dist/_app_instead of/path/to/addonfor the app tree, and same for the public tree.This is one part of addressing the "ignoring source files" approach discussed in https://github.com/embroider-build/addon-blueprint/issues/32, the other (for the addon tree that is not covered by addon-shim) is this PR: https://github.com/embroider-build/ember-auto-import/pull/623
I tested this in a local installation, and it did have the desired effect (when combined with the other PR): when changing only source files and not having the addon's build running in parallel, the app would not rebuild, as it would be expected.