Published blade components overwrite existing ones

[AbdullahObaid]

As mentioned before here https://github.com/laravel/jetstream/issues/1269 , This PR https://github.com/laravel/jetstream/pull/1118 changed the way Jetstream components are handled. Although as the PR author @jessarcher said

to give the user a better sense of ownership over the components, and to leverage Laravel's anonymous components. This also means the jet- prefix is no longer used, but I think that's a good thing.

This sense of ownership might be a personal opinion. Moreover, it introduced new issue of overwriting existing components files. Also, copying something like 30+ component files with generic names like ( modal, banner, button, input .. etc ) under the components directory directly doesn't make any sense !

As @amihailov said :

Since Jetstream components / resources are package specific, they should live in their own space.

Also, most of Laravel first party packages publish files under specific vendor directory, so why to change the behavior here?

I know Jetstream is mainly meant for new Laravel projects, but why it should be like that ?

In many projects, we start by developing the main business logic and keeps the user management part to be handled later. This behavior makes it impossible to adopt Jetstream after starting working on any any other part of the project.

[driesvints]

Moreover, it introduced new issue of overwriting existing components files.

This behavior makes it impossible to adopt Jetstream after starting working on any any other part of the project.

Jetstream is a scaffold tool which is only intended for new Laravel applications. Using it on existing applications can lead to overwritten code like you're experiencing. Please see the Jetstream docs: https://jetstream.laravel.com/installation.html

[AbdullahObaid]

Even that jetstream is intended for new Laravel applications, it doesn't make any sense to add all of those components under the component directory directly. They need to live in there own directory such as /components/jetstream/

[mokhosh]

I think if you can update your laravel version and your livewire version, it's very understandable that you'd want to update your jetstream version as well, isn't it?

[AbdullahObaid]

@driesvints @taylorotwell So is that design decision discussable ? I can contribute that change, but I don't want to waste my time then got rejected !

[jessarcher]

@AbdullahObaid Why should the components live at components/jetstream? They aren't vendor files that you should re-publish every time Jetstream changes. Those components are intended to be customised and used throughout your application rather than having to maintain and consistently style one set of components for the pages scaffolded by Jetstream and another set for the rest of your application.

[jessarcher]

Also, most of Laravel first party packages publish files under specific vendor directory, so why to change the behavior here?

In other packages, those assets are specifically used by the package. Sometimes, they must be published purely to be served from the public directory. In other cases, it's a mechanism for customising the specific behaviour of that package. In either case, the assets are package-specific.

Jetstream is quite different. It's a starting point to build a custom application. The components are intended to be used throughout your application to maintain a consistent look and feel and prevent you from needing to re-engineer common components like buttons and modals. Additionally, the only code that references those components (i.e. the initial pages) is also part of your application code, not the package. They aren't published purely as an entry point to customize something inside the package.

[amihailov]

I understand your point of view but practically it is, well... not practical. I think we were all happy when Jetstream lived in its own space and wasn't posing itself like an obstacle whitin the application because of generic elements with a very specific purpose are placed in a very generic directory. You can't just place components that are named "input" or "delete" or "button" which serve only Jetstream and consider it is ok.

As other maintainers of Jetstream said before - it is what it is and read the docs, and I am ok with that. Your software, your rules. All I want to say that it is no so much obvious and practical as intended. For this reason I abandonned the use of Jetstream for our new applications. Still Jetstream is a great piece of functionnality !

[jessarcher]

I think we were all happy when Jetstream lived in its own space [...]

I wasn't. I felt weird using components with "jetstream" in the name throughout my application in places that had nothing to do with the initial scaffolding. I also worked with developers who must have felt the same because they created a separate set of UI components, and the application then didn't feel consistent between pages and maintaining two sets of components was a burden.

[...] generic elements with a very specific purpose are placed in a very generic directory. You can't just place components that are named "input" or "delete" or "button" which serve only Jetstream and consider it is ok.

The point is that those components dont only serve Jetstream and are generic. They are intended to be used throughout your application and customised (or replaced) as needed.

The intention of moving them out of the "jetstream" directory was so that:

1. You felt like you could use them anywhere.
2. You wouldn't create your own generic components and have two sets of buttons, two modals, two dropdowns, etc., where part of your app looks and behaves one way, and the rest looks and behaves differently.

One of the first things I do with a fresh Jetstream install is customise those components' styles and occasionally add extra functionality. I use them throughout the application, and life is good.

Should the page layouts, profile pages, dashboard, login pages, etc. all live in a Jetstream directory too?

[amihailov]

The point is that those components dont only serve Jetstream and are generic. They are intended to be used throughout your application and customised (or replaced) as needed.

And that is exactly the problem we others have. We do not want for a package like Jetstream to have any assumptions or good intentions of the kind. Apparently we are minority, so that's ok.

I felt weird using components with "jetstream" in...

I don't see at all where is the wiedness here, but ok, color & taste...

Friction apparently is that Jetstram is considered by you to be a starting point for an application and we see it more as an additional functionnality but not as "a starting point".

[AbdullahObaid]

@jessarcher Even it is stated that Jetstream is an app scaffolding, in its current state it's a complete authentication solution with teams, 2FA, profile management ..etc and nothing more. If this was the case, and Jetstream want to be a scaffolding package, then all of the components should be designed to to be reusable with a complete documentation, something like filament which is not currently the case.