-
Notifications
You must be signed in to change notification settings - Fork 71
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
Does not work with async plugins #105
Comments
I added a workaround to ignore anything object-hash can't process (see objecthash branch, |
I must admit I'm surprised this haven't been more of an issue so far since async functions are extremely common by now 😀. Which is also why I think that simply ignoring it will lead to a great deal of cache issues. The PR I submitted to object-hash some time ago was a consequence of this very issue, and I would suggest that you remove the dependency on object-hash. I'm pretty confident that the PR submitted some time ago would work just fine since it matches on the same value as provided in the error message and passed both unit tests and solved the issues in this plugin, so feel free to depend on the PR rather than the NPM package here. @vwxyutarooo, an immediate workaround is to set |
@wessberg Yeah, I guess not many rollup plugins have async in their interface yet. Do you know a better way of hashing objects? I need to create a cache key based partly on rollup configuration object (and therefore containing source of all the plugins used) that is passed in on startup. |
btw, to clarify -- the problem applies to async stuff in rollup config itself. Async in the code being transpiled is not a problem, because code is hashed based on source text. |
Hmm, well, you could apply sha1 to the result of JSON.stringify'ing the entire config with a custom replacer that maps plugins to their {
// ...
treeshake: true,
plugins: [
myPlugin1(),
myPlugin2()
],
// ...
} Could be converted into the following JSON representation: {
"treeshake": true,
"plugins": [
"name-of-my-plugin-1",
"name-of-my-plugin-2"
]
} And then you could apply sha1 and get a base64 string out or something like that which you could use as cache key? |
I was thinking along those lines, but wouldn't that remove even more things from consideration for cache? I suspect |
I suppose I could incorporate a hash of |
Thanks guys discussing about this issue. Actually |
@vwxyutarooo, I was under the assumption that |
I don't know how this affected to object-hash result, However the |
I reworked cache a bit so |
In 0.17.0 now |
For another workaround not using the import requireContextORIGINAL from 'rollup-plugin-require-context'
const requireContext = (options) => {
const plugin = requireContextORIGINAL(options)
return {
name: plugin.name,
transform(code, id) {
return plugin.transform(code, id)
}
}
} Namely, making |
…o rollup-plugin-typescript2 (#324) issue ezolenko/rollup-plugin-typescript2#105
Thought I'd add an update for folks here that the root cause here was finally fixed in puleos/object-hash#90 (very similar to puleos/object-hash#68 referenced above) and here in #203. No need to use |
What happens and why it is wrong
This plugin does not work with plugin which containing async/await syntax caused by object-hash issue and tscache.ts. I think this is hard to fix object-hash because there is no way to detect asyncfunction now. So is there any alternative without object-hash?
Environment
Versions
rollup.config.js
tsconfig.json
No relevant.
package.json
No relevant.
plugin output with verbosity 3
The text was updated successfully, but these errors were encountered: