-
Notifications
You must be signed in to change notification settings - Fork 27
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
ENAMETOOLONG when opening tmp-globalize-webpack generated files #42
Comments
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. About the issue here, would you be open to changing the encoding for |
Sure, what's your proposal? I see in your commit you're using a hash function. Does it handle conflicts? |
Good point! 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.
The text was updated successfully, but these errors were encountered: