[Proposal] Allow global helper functions to be disabled

[imliam]

Global helper functions cause problems when they conflict with another defined function - and currently, there is no way to solve these issues in the framework.

I am proposing a new configuration setting that you can add to your project's composer.json file. If the value is set to true it will stop all helper functions being defined.

{
    "extra": {
        "laravel": {
            "disabled-functions": true
        }
    }
}

Another option would be to pass an array of function names to the configuration. If this is done, only the specified functions will be omitted.

This could be a useful option if people experience a function naming conflict like in laravel/ideas/issues/1569 - letting them disable the conflicting functions while keeping the rest.

{
    "extra": {
        "laravel": {
            "disabled-functions": ["app", "resolve"]
        }
    }
}

This could also be a step towards deprecating the remaining global helper functions from the core framework, as has been done with the string and array functions, if the Laravel team wants to go in that direction.

There is a working branch of this available here: https://github.com/imliam/framework/commits/deprecate-helpers

See my original PR for more information: https://github.com/laravel/framework/pull/28254

[garygreen]

As a proponent of ditching helper functions, I am against this suggestion of ditching every single helper function in Laravel. And I especially think it shouldn't be configurable (it would create confusing and brittle libraries for package developers)

Helper functions can be useful. Though I do think there should be a balance between usefulness, regularity of usage and not overly polluting the global namespace unnecessarily - this is why str_ and arr_ helpers have been removed, only a handful were often used by most developers so polluting the global namespace with excess unused helpers didn't make any sense.

For helpers that are often used, it's a much more enjoyable developer experience writing collect() than Laravel::collect() or now() instead of Carbon::now()

I personally think if we are to remove more helpers, it should be done in a calculated way e.g. work out if the helper is any shorter than just using a class, also determine how often it's likely to be used, and then decide if it's worth deprecating that helper or not. I proposed this waaay back in https://github.com/laravel/ideas/issues/194 which has helped ditch the arr and str helpers.

[imliam]

I agree that it's a much more enjoyable experience to use the short helper names - I use them myself all the time.

The problem is that keeping any in the global space with no way to disable them means there is NO way to resolve naming conflicts, which is all this aims to give a solution for - the aim isn't to outright remove them all.

[mfn]

I'm in the "pro disable global helper" camp.

IMHO the only way to satisfy all parties it to:

• rewrite all framework code to use non-global functions (namespaced function or just in a class, doesn't matter) => to fix the name clashes when you've to integrate with other software
• make the global helpers optional, i.e. only for apps (and should be absolutely discouraged for libraries, too)
  • could be simple a package being installed by default when using Laravels installer but for the minority of people for whom this is a PITA, it's a no-brainer to disable them

[donnysim]

It takes only one global function clash to prevent an integration, for example you want to integrate/access laravel session into a file manager. So as much as I like global functions, I do want the ability to disable them, or have them namespaced

[gcornelisse]

The helpers are useful, but I think they should be namespaced. Right out of the gate trying to start a new solution for our enterprise clients, we ran into conflicts. For all the pressure to use namespaces these days, I'm surprised Laravel still has anything in the global namespace.