In lieu of rolling our own, let's decide on a third party to incorporate.
I'm envisioning something similar to ircmaxell/password_compat being included in system/core/compat, thought we may want to plan third-party components to be in a more obvious location.
I'm against _shipping_ a third-party component together with CI.
The goal of using a third-party component is to avoid duplicating code and maintenance efforts. Including a copy of a third-party library in the framework's codebase means that the library is maintained _as a part_ of the framework and then you fail to meet that goal.
I'd rather recommend a popular library in the documentation instead.
Why not use composer to manage third party package?
composer not work in china. CI is good for phper who in china. thank you for you effort
Also, we really ought to deprecate this and wrap the password library instead.
https://github.com/ircmaxell/RandomLib is a very solid choice. @ircmaxell
random_string can (and probably should only) be used for non-password scenarios. It's a string helper and not a password helper. I use it for example to generate order ids.
Most helpful comment
random_string can (and probably should only) be used for non-password scenarios. It's a string helper and not a password helper. I use it for example to generate order ids.