Skip to content
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

._end naming collision #52

Closed
jpodwys opened this issue Jan 29, 2017 · 3 comments
Closed

._end naming collision #52

jpodwys opened this issue Jan 29, 2017 · 3 comments

Comments

@jpodwys
Copy link
Owner

jpodwys commented Jan 29, 2017

In a superagent release some time since 1.8.0, the superagent team has begun using request._end internally. Because this is something superagent-cache has done for a long time, there is now a naming collision for users of more recent versions of superagent.

Because ._end is listed as an API method in superagent-cache's docs, the only way to avoid the name collision is to release a breaking change (2.x) of superagent-cache that changes my ._end function's name.

Because there are a number of things I'd like to include in superagent-cache's 2.x release (including compatibility with the latest superagent releases as well as everything listed in #25), fixing this issue is not trivial. My goal of keeping superagent-cache and all of its related cache modules as well as superagent-cache-plugin in major release sync only increases the maintenance burden.

If this bug is causing you problems, please comment on this issue.

@kangaroo5383
Copy link

This is preventing us from using this, is there a workaround atm?

@jpodwys
Copy link
Owner Author

jpodwys commented Mar 10, 2017

Have you tried using superagent-cache-plugin? It doesn't have this issue.

@jpodwys
Copy link
Owner Author

jpodwys commented Mar 14, 2017

@kangaroo5383 does superagent-cache-plugin meet your needs, or would your use case benefit from using superagent-cache?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants