Sentry-laravel: Facade name collision with existing package

[dcramer]

I'm trying to install Sentry on a Laravel 5 project but I'm already using Cartalyst Sentry for user authentication - which has an existing facade for "sentry." Is there a workaround for this?

[dcramer]

My personal opinion is "this isn't our problem", but I want to ensure Sentry is usable. I think you can use app('sentry') instead of the Facade, but maybe I'm wrong. Would be helpful to know what other Laravel authors think here. If we _do_ need a Facade, I'd like to find a way to make a secondary Facade available (though I have no idea what we'll call it).

Either way, I have no desire to cater to other people using the Sentry name for their own projects, especially since it dates back so far (and additionally we have likely trademark law on our side, even if it doesn't need to apply here). We have this issue in Ruby as well, which might be the same project. It's awfully annoying/confusing, and we should not suggest "people can keep naming things Sentry and force us to deal with the conflicts".

[stayallive]

If it's not clashing in the IoC container (so app('sentry') is not the issue) people can simply change the facade name in their config/app.php.

'Sentry' => Sentry\SentryLaravel\SentryFacade::class,

To:

'SentryTracker' => Sentry\SentryLaravel\SentryFacade::class,

Or something like that (you could also use Raven / sentry.raven as facade / IoC name).

Although looking at their (depracated) code on GH it _is_ clashing in the IoC container. The only way around that is renaming Sentry in the IoC container (for this package or the cartalyst one 😉 ).

Possibly using sentry.raven is an solution since that would not clash with a package using sentry as IoC binding I believe.

[dcramer]

@stayallive thanks! fwiw we intend to completely remove "Raven" from the history books (too confusing to users)

[stayallive]

@dcramer the using "Raven" is a terrible idea :P But no idea what would be nice to use instead then.

[davzie]

I'm having this issue which is also stopping me using Sentry on an old Laravel 4 project that uses Cartalyst's package namespacing too. I actually took the service provider and botched it to use a new Facade called "Sentryerrors" instead, but alas this isn't working. Any idea how I can use my own provider to make this work? I love Sentry and desperately need error logging for this app :)

[stayallive]

You should be able to copy the facade and service provider into your own application like this: https://gist.github.com/stayallive/2adc8a92aaa64ca5427f50141f715561

And add this Facade instead of the one in the docs:

'SentryErrors' => App\Support\SentryFacade::class,

And add this ServiceProvider instead of the one in the docs:

App\Support\SentryServiceProvider::class,

Also the config file is renamed to sentry-laravel.php in the gist above so you should rename the config file if it was already created.

Note: this code is untested and you might want to adjust the namespaces to suit you application.

[davzie]

So far I've created a custom Facade that returns sentryerrors too but to no avail :)

[stayallive]

Yes, this won't work since the service providers registers Sentry under a different key, the Facade is just a shortcut. Check out the gist and look at the original service provider next to it you will see what is happening 😉

[davzie]

I got so close and yet felt so far, but you completed the journey, you're my Samwise Gamgee! Thanks @stayallive :)

[dcramer]

You could also just extend our provider right?

class SentryCompatServiceProvider extends SentryLaravelServiceProvider

If so maybe we'll consider offering this as part of core as an alternative configuration, but not the default/recommended.

[stayallive]

That is possible yes. However you still need to copy over much code. Maybe add a property that indicates the IoC key used (or maybe that was wat you ment already xD)? Although the same trick is not possible for the facade, so you either need to make your own facade or use none at all.

[davzie]

I think having a protected property on the service provider and referring to that would be a great way to start. You could perhaps provide a second facade for alternative naming and as a result, then an extended service provider so people don't even need to create their own and could instead reference something like

SentryCompatServiceProvider

instead. Just a thought, but thanks for all the help :)

[stayallive]

If you would provide a extra service provider with changed naming I would say just change it in the main one. Two service providers is probably going to cause more confusing than it is solving.

[hackel]

One caveat about my fix: I didn't change the name of the config file, which means that both this Sentry and Cartalyst Sentry will need to store data in config/sentry.php. This is obviously far from ideal. Does it make sense to change the config key as well?

In addition, the logic for binding the user context will fail unless you have created a (Cartalyst) Sentry driver for the Laravel authentication mechanism. Mine is very simple, and based on this:
https://github.com/Malezha/sentry-auth-laravel (adapted for L5). This allows e.g. $app['auth']->user() to work. Then, you also have to implement the getAuthIdentifier() method on your User model.

[stayallive]

@hackel IMHO I think that is probably a good idea to keep the config key "in sync" with the IoC registered key. Since the only reason someone is changing the IoC key is because they have a conflict with another Sentry package (probabaly the Cartalyst one) and that means the config file is also combined which is as you said far from ideal.

And the binding of the user context will fail but it is only an example, so you can implement however you see fit (it is also not included in this package only in the docs) so if you use Cartalyst Sentry you can adapt the example to work with their Auth facade or user resolver thingy.

[hackel]

@stayallive Agreed, I updated it to use the $abstract property as config file name as well.

[stayallive]

Looks like this was fixed by you in #39 🎉