-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Add a test helper #341
Add a test helper #341
Conversation
Add a delete method to manifest Remove delete for now Remove exist? for now and document in readme Fix wording Fix sentence Add a checksum so it doesn't compile unless changed Add namespace Make rubocop happy
end | ||
|
||
def compile_webpack_assets | ||
Rails.cache.fetch(["webpacker", "manifest", checksum]) do |
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 cache key will only be invalidated when your files change, right? What if, for example, you bump the version of a dependency in package.json? I think it'd be best to avoid caching unless we can use the same digests provided by webpack.
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.
@javan Yepp that's right. Good point 👍 Perhaps we should watch package.json
and yarn.lock
for changes too? The compile task slows down the tests so it's best to cache because we won't be able to get new digests from webpack until it's compiled (which is same thing as re-compiling) unless I am missing something??
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.
Added yarn.lock and package.json to watch list
Closing in favor of #360 |
@dhh As we discussed the other day this addresses compiling assets in tests based on @javan's idea. Also removed the rake task enhancements because it's compiling twice and could also lead to confusion, this way it's more clear. What do you think?
We will need to merge the reload PR #292 first because that will make sure that manifest change has been picked up whenever it changes.