Conversation
| if (!Array.isArray(list)) { | ||
| throw new TypeError('must be an array'); | ||
| } | ||
| opts = opts || config.globOptions; |
There was a problem hiding this comment.
Should we merge these here, instead of overriding them?
There was a problem hiding this comment.
Actually, we're not using opts anymore (it was added for something, but we refactored the code to not need it). I think it's cleaner to just use config.globOptions instead.
I don't think our code should ever need to pass options to glob.sync(). We experimented with using glob.sync('dirName/*', {dot: true}) for ls -a, but it's much easier to just us fs.readDirSync() instead (it's simple, it's faster, and it actually works correctly for a directory named dir*With?Glob[chars]/).
|
One nit, and can we get this rebased off master? Thanks! |
|
Rebased. I changed |
|
LGTM! |
|
re- LGTM |
Allow users to customize the settings of `glob.sync()` (if they so-desire). This doesn't change the default behavior.
|
re-re- LGTM (rebased off master) |
This removes support for configuring `config.globOptions`. Exposing this variable makes it difficult to change (or upgrade) our glob library. It's best to consider our choice of glob library to be an implementation detail. As far as I know, this is not a commonly used option: https://github.com/shelljs/shelljs/issues?q=globOptions currently shows no GitHub issues of users using this option, and there was never really a motivation for why this needed to be exposed (#400 exposed the option just because we could, not because we should). This is one step toward supporting Issue #828.
This removes support for configuring `config.globOptions`. Exposing this variable makes it difficult to change (or upgrade) our glob library. It's best to consider our choice of glob library to be an implementation detail. As far as I know, this is not a commonly used option: https://github.com/shelljs/shelljs/issues?q=globOptions currently shows no GitHub issues of users using this option, and there was never really a motivation for why this needed to be exposed (#400 exposed the option just because we could, not because we should). This is one step toward supporting Issue #828.
This deprecates support for configuring `config.globOptions`. Exposing this variable makes it difficult to change (or upgrade) our glob library. This discourages users from depending on this config option going forward. If anyone is using `config.globOptions` then it should continue to function, however this support is not promised for the long-term. As far as I know, this is not a commonly used option: https://github.com/shelljs/shelljs/issues?q=globOptions currently shows no GitHub issues of users using this option, and there was never really a motivation for why this needed to be exposed (#400 exposed the option just because we could, not because we should). This is one step toward supporting Issue #828.
This deprecates support for configuring `config.globOptions`. Exposing this variable makes it difficult to change (or upgrade) our glob library. This discourages users from depending on this config option going forward. If anyone is using `config.globOptions` then it should continue to function, however this support is not promised for the long-term. As far as I know, this is not a commonly used option: https://github.com/shelljs/shelljs/issues?q=globOptions currently shows no GitHub issues of users using this option, and there was never really a motivation for why this needed to be exposed (#400 exposed the option just because we could, not because we should). This is one step toward supporting Issue #828.
Allow users to customize the settings of
glob.sync()(if they so-desire). This doesn't change the default behavior.I imagine this is a feature a few users may want (users wanted something similar for
exec()options in #163, #284, #132 ).