-
Notifications
You must be signed in to change notification settings - Fork 26
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
Laravel 8 deprecation #60
Comments
@DCzajkowski it's a good question to discuss for sure; I was wondering the same. Thanks for putting it out here. In the apps where I've used your package's tests I've wanted to ensure that my app's auth scaffolding wasn't broken by anything I might be refactoring in-app, especially when I've customized a few parts of the auth process (overriding laravel/ui's methods in my controllers/models). So I've been thankful for having auth-related tests in my own test suite so that I can spot quickly whether something has gone awry when making changes. (It even once caught a bug I'd created only by refactoring some styling on auth pages, because I'd broken some HTML that the browser wasn't even exposing. That was a weird one, but the tests saved me from putting the bug into production.) Nevertheless, that was when the scaffolded code was without a test suite, so your package bridged that gap. I see value in keeping this package maintained until laravel/ui is fully retired. It seems they're still planning some ongoing support for a little bit ... but I won't be surprised if they're reluctant to support it into Laravel 9 in the spring. One thing that I haven't researched is how "portable" the jetstream tests are in terms of being able to copy them over into my own project and tweak them to match my app, so that I can continue testing my auth system when making app changes. I'm sure others will have the same question, so if someone wants to write up some steps for doing that it might be a nice way to retire this package when the time comes. To be clear: I'm grateful that you've put this package together and maintained it consistently. Thanks! |
Thank you @drbyte for your feedback. I 100% agree. From what I have seen upgrading to Jetstream doesn't seem like a viable option. It seems like it is a completely new implementation, that is tightly coupled to Inertia.js or Livewire. Of course it wouldn't be impossible, rather inconvenient, hard, and not worth the effort. I might be wrong though and if you try it let me know! :) I'll try to maintain this package as long as laravel/ui is a thing. 😉 |
I'm slightly late to this game I guess, but here are my two cents to the topic... First and foremost, big credit for @DCzajkowski putting this package out there - thank you. It was such a revelation to stumble upon it when I did - I haven't even used the auth scaffolding of Laravel before then! Yes, I know, if I use Jetstream, it's all covered, tested behind the scenes... but it was kind of the same with the old scaffolding as well, wasn't it? My biggest concern was not the trust but rather that there was nothing to prove if my application is actually worked correctly? Nothing to prove that I even have an auth scaffolding in place at all? From that perspective, nothing has changed to me - what has, that's merely implementation detail? What if (as most of the applications I build) needs something slightly different in the implementation? As far as Jetstream is concerned, what if I need to change the action controllers of the authentication for some reason? I mean I can write all tests that uses logged in users or guests and have the application work "correctly" without even pulling Jetstream in - but my users would never be able to register or log in? I believe "leaving all to Jetstream" would not be the best option. Replicating all Jetstream tests wouldn't be either - I'm thinking of something in-between where we could assure our application implements all the scaffolding it needs and works appropriately even if we have some quirks around it, with minimal redundancy... Fortify and Jetstream builds on top of invokable action classes - can we not test the functionality in two steps? One would test whether the correct action is fired at the appropriate times while the other one would unit test the outcome of the actual action in our application? A bit like the way you would test an event and its listener? Just some food for thought there... 🤔 |
Ditto! |
Unfortunately, I have to agree. The biggest problem will be finding a solution that is just right. Let me think about it, but I don't know if I'll have enough time to tackle it all by myself. Stay tuned, I guess :) |
Great to know, thanks @drbyte 💪 |
Jetstream tests from Taylor. https://twitter.com/taylorotwell/status/1339232257643601921?s=21 |
Laravel 8 marked the laravel/ui package as deprecated in favor of Jetstream.
From what I can see, Jetstream hides all of its controllers inside the package, meaning it doesn't make sense to test those controllers, as Jetstream has its own tests.
From what I understand, using this package (and upgrading it to new releases) makes only sense for people already using the old authentication flow, who want to upgrade their existing projects. The question I have as a maintainer — is it worth it?
I am @'ing a few people who have contributed/were active on/are watching this repo. Please let me know what you think. See #54 and the deprecation notice in particular to get a sense of what all of this means. :)
Have a good day,
Dariusz
cc: @drbyte @nhedger @benyou1969 @zaknesler @FaizAhmadSE @drehimself
The text was updated successfully, but these errors were encountered: