Open cprodescu opened 7 years ago
Ideally, this plugin shouldn't use the temporary files if we instead knew the answer for this question http://stackoverflow.com/q/31147779/798133
That makes sense.
The closest development I could find on that topic is rmarscher/virtual-module-webpack-plugin. It is built on top of implementation details of enhanced-resolve
, so it's fragile.
About the issue here, would you be open to changing the encoding for GlobalizeCompilerHelper . getModuleFilepath
(downside of current implementation is that it doubles the length of the path).
About the issue here, would you be open to changing the encoding for GlobalizeCompilerHelper . getModuleFilepath (downside of current implementation is that it doubles the length of the path).
Sure, what's your proposal? I see in your commit you're using a hash function. Does it handle conflicts?
Good point!
It does not handle conflicts, but it's using the sha-1
algorithm, same as git
. The chance of finding a collision is very low (Google has recently published a paper on how they managed to generate a collision after 9 quintillion sha-1 computations). Discussions on sha-1 collisions:
https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html
http://stackoverflow.com/questions/9392365/how-would-git-handle-a-sha-1-collision-on-a-blob
I will add code which throws an error if there is a collision (as unlikely as it is, I agree it shouldn't silently fail). Please let me know if you prefer a different approach altogether.
Sounds sane, specially if this (i.e., use hash instead of filename) is a feature that could be turned on/off by an option. Would you like to submit a PR?
@necolas do you have any input about it? Thanks
Sure, will look into it!
I think the option is a bit unnecessary for the user, especially since the internal behavior is a workaround for a missing feature in webpack.
However, I don't have a strong opinion, just a few questions:
We use globalize-webpack-plugin in our project. Everything works great locally, however in CI environment (distributed pants over a mesos fleet), the sandbox root is nested deeply and the file paths generated by globalize-plugin are too long to read (throwing
ENAMETOOLONG
onfs.openSync
).This is an uncommon issue, affecting very few projects, but I'm wondering what your suggestion would be.