You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm using broccoli-babel-transpiler with a bunch of custom Babel plugins. Among other things, these include a wildcard module resolver to allow for things such as import "tests/**/*.spec" - in other words, my source file depends on a glob expression, not a single file. When a new test is added to the project, or when a test file is removed, the source file containing the wildcard import (presumably /alltests.js or similar) needs to be rebuilt.
Can I achieve this with the current dependencyInvalidation mechanism?
On first reading of the code, I don't believe the current implementation can do this, but a fix should be fairly simple. Storing glob-like dependencies in a separate inverse-map and matching changes against each registered pattern after the regular dependent lookup should be sufficient.
Is this something you would be interested in?
The text was updated successfully, but these errors were encountered:
I wrote the dependency invalidation feature. I think this would be a good feature to add. I'm happy to review your PR if you still want to make one up.
I'm using broccoli-babel-transpiler with a bunch of custom Babel plugins. Among other things, these include a wildcard module resolver to allow for things such as
import "tests/**/*.spec"
- in other words, my source file depends on a glob expression, not a single file. When a new test is added to the project, or when a test file is removed, the source file containing the wildcard import (presumably/alltests.js
or similar) needs to be rebuilt.Can I achieve this with the current dependencyInvalidation mechanism?
On first reading of the code, I don't believe the current implementation can do this, but a fix should be fairly simple. Storing glob-like dependencies in a separate inverse-map and matching changes against each registered pattern after the regular dependent lookup should be sufficient.
Is this something you would be interested in?
The text was updated successfully, but these errors were encountered: