`--using` doing too much

[joshmanders]

Installer Version

5.14

Description

When using a userland starter using the --using flag, the installer is doing too much. If no post-root-package-install is set the installer just flat out kills and doesn't finish any steps (not all starters may need this script), and if the starter doesn't necessarily need other things such as running npm install and build, it still prompts for and runs those.

Those extra steps should only happen for the official Laravel starters. Otherwise you get unintended side effects.

For example, I use Skeletor in all my starters and since Skeletor prompts the user for additional information specific to that starter, the laravel installer clobbers that and outputs similar information and asks things that shouldn't be asked.

As you can see from this screenshot, the > @php -r "file_exists('.env') || copy('.env.example', '.env');" is the beginning of the additional unnecessary steps performed by the installer.

I can submit a PR fixing this if necessary.

Steps To Reproduce

laravel new --using starter/laravel my-app

[HichemTab-tech]

It's the starter kit that should be compatible with the installer, not the other way around. You are already customizing a lot by using Skeleton, so why not just continue the installation manually without using the Laravel installer? In fact, it would make a lot more sense if you created your own starter kit and used it as a template repository.

So instead of relying on the Laravel installer, I really recommend doing your own customization, because beyond using simple starter kits, the Laravel installer won't be useful for such cases anyway.

And the final point is that the Laravel team is spending so much time maintaining the installer and starter kits, which I don’t think is worth it at all. Instead, they could use this time to develop new features or fix old bugs. It would be a lot better, because now I feel like these starter kit/installer issues are slowing down Laravel development.

This is my point of view, thanks! ;)

[joshmanders]

I don't know what your rant has to do with any of this.

[tnylea]

Hey @joshmanders, I'd be open to seeing a PR for this 😉 I agree that the installer may be running things that are not necessary for all community starter kits.

As long as it still works with our Official starter kits and is an improvement, I don't see any reason why we shouldn't merge it in. I appreciate it!

[joshmanders]

Excellent @tnylea I'll start working on a PR today.

[devajmeireles]

Dropping here the same comment I did in the PR:

Wouldn't a better way to fix this be to check if composer.json has post-root-package-install before running it, rather than just running it on the official Laravel starter kits?

There are dozens of starter kits already created by the community. Changing them now might not be very easy, from a community awareness perspective! As I mentioned above, in my opinion, the best thing to do is to run post-root-package-install only if it exists in composer.json

[joshmanders]

Wouldn't a better way to fix this be to check if composer.json has post-root-package-install before running it, rather than just running it on the official Laravel starter kits?

It's doing more than just executing that command. Asking for a testing suite choice, copying .env.example to .env and updating the .env file could also be issues for custom starter kits.

[devajmeireles]

Wouldn't a better way to fix this be to check if composer.json has post-root-package-install before running it, rather than just running it on the official Laravel starter kits?

It's doing more than just executing that command. Asking for a testing suite choice, copying .env.example to .env and updating the .env file could also be issues for custom starter kits.

I don't think I understood correctly.

In my opinion, starter kits should be based on the examples suggested by laravel/livewire-starter-kit, for example. There are 4 commands in composer.json

• post-autoload-dump
• post-update-cmd
• post-root-package-install
• post-create-project-cmd

The project https://github.com/aniftyco/skeletor doesn't seem to follow the structure of an acceptable starter kit, in my opinion. I created a starter kit, and it's working very well, it's a similar model to the official Livewire offered by Laravel, but obviously, I could move the instruction that exists on post-root-package-install to post-create-project-cmd

We must remember how Laravel creates the project. It uses the composer create-project, which in turn needs to trigger the scripts mentioned above to perform the necessary steps to prepare the project.

If the idea here is to prevent the post-root-package-install script from running by default, then just check if it exists before simply invoking it. Dozens of people in the community may need post-root-package-install in their starter kits.

[joshmanders]

Wouldn't a better way to fix this be to check if composer.json has post-root-package-install before running it, rather than just running it on the official Laravel starter kits?

It's doing more than just executing that command. Asking for a testing suite choice, copying .env.example to .env and updating the .env file could also be issues for custom starter kits.

I don't think I understood correctly.

In my opinion, starter kits should be based on the examples suggested by laravel/livewire-starter-kit, for example. There are 4 commands in composer.json

• post-autoload-dump
• post-update-cmd
• post-root-package-install
• post-create-project-cmd

The project https://github.com/aniftyco/skeletor doesn't seem to follow the structure of an acceptable starter kit, in my opinion. I created a starter kit, and it's working very well, it's a similar model to the official Livewire offered by Laravel, but obviously, I could move the instruction that exists on post-root-package-install to post-create-project-cmd

We must remember how Laravel creates the project. It uses the composer create-project, which in turn needs to trigger the scripts mentioned above to perform the necessary steps to prepare the project.

If the idea here is to prevent the post-root-package-install script from running by default, then just check if it exists before simply invoking it. Dozens of people in the community may need post-root-package-install in their starter kits.

You're making assumptions that all starter kits need to copy .env, some may be more advanced and want to do extra stuff, such as mine here https://github.com/composer-starters/laravel/blob/master/Skeletorfile.php

By erroring out if no post-root-package-install exists is a failure on the install part. If nobody needs that step in their starter and remove it, the installer should continue on.

It's also assuming other things that may not be the same for another starter kit. None of my concerns have to do with Skeletor's usage with the starter kit and just various other reasons one would want to make a starter.

[devajmeireles]

Wouldn't a better way to fix this be to check if composer.json has post-root-package-install before running it, rather than just running it on the official Laravel starter kits?

It's doing more than just executing that command. Asking for a testing suite choice, copying .env.example to .env and updating the .env file could also be issues for custom starter kits.

I don't think I understood correctly.
In my opinion, starter kits should be based on the examples suggested by laravel/livewire-starter-kit, for example. There are 4 commands in composer.json

• post-autoload-dump
• post-update-cmd
• post-root-package-install
• post-create-project-cmd

The project https://github.com/aniftyco/skeletor doesn't seem to follow the structure of an acceptable starter kit, in my opinion. I created a starter kit, and it's working very well, it's a similar model to the official Livewire offered by Laravel, but obviously, I could move the instruction that exists on post-root-package-install to post-create-project-cmd
We must remember how Laravel creates the project. It uses the composer create-project, which in turn needs to trigger the scripts mentioned above to perform the necessary steps to prepare the project.
If the idea here is to prevent the post-root-package-install script from running by default, then just check if it exists before simply invoking it. Dozens of people in the community may need post-root-package-install in their starter kits.

You're making assumptions that all starter kits need to copy .env, some may be more advanced and want to do extra stuff, such as mine here https://github.com/composer-starters/laravel/blob/master/Skeletorfile.php

By erroring out if no post-root-package-install exists is a failure on the install part. If nobody needs that step in their starter and remove it, the installer should continue on.

It's also assuming other things that may not be the same for another starter kit. None of my concerns have to do with Skeletor's usage with the starter kit and just various other reasons one would want to make a starter.

That's why I said the most logical thing to do is to check if post-root-package-install is set before running. I think if you open a PR like this, Taylor would agree.

[inmanturbo]

I think the fact that we can fork the official starter kits and sprinkle in our own functionality without breaking compatibility and still get all the nice install features is a huge value add.

In the case where you need to deviate quite a bit from the official starter kits anyway or you are doing something else altogether, why not just use composer create-project, or git clone?

[joshmanders]

I think the fact that we can fork the official starter kits and sprinkle in our own functionality without breaking compatibility and still get all the nice install features is a huge value add.

In the case where you need to deviate quite a bit from the official starter kits anyway or you are doing something else altogether, why not just use composer create-project, or git clone?

I literally already explained this stuff here. There's many people who make vast changes to their starter and being able to tell already existing laravel users to just do laravel new --using my/starter is easier then having a 6 step install instructions to recreate all the additional things the installer does just because it flat out dies if you don't have a composer script that it tries to call.

[inmanturbo]

I think the fact that we can fork the official starter kits and sprinkle in our own functionality without breaking compatibility and still get all the nice install features is a huge value add.
In the case where you need to deviate quite a bit from the official starter kits anyway or you are doing something else altogether, why not just use composer create-project, or git clone?

I literally already explained this stuff here. There's many people who make vast changes to their starter and being able to tell already existing laravel users to just do laravel new --using my/starter is easier then having a 6 step install instructions to recreate all the additional things the installer does just because it flat out dies if you don't have a composer script that it tries to call.

Right, well checking for a post-root-package-install is one thing, but what about internal starter kits at an agency for instance, that are identical in every way to the official ones, aside from adding a some branding for example, and want the rest of the behavior to stay the same and are using a fork and tracking upstream changes?

[joshmanders]

I think the fact that we can fork the official starter kits and sprinkle in our own functionality without breaking compatibility and still get all the nice install features is a huge value add.
In the case where you need to deviate quite a bit from the official starter kits anyway or you are doing something else altogether, why not just use composer create-project, or git clone?

I literally already explained this stuff here. There's many people who make vast changes to their starter and being able to tell already existing laravel users to just do laravel new --using my/starter is easier then having a 6 step install instructions to recreate all the additional things the installer does just because it flat out dies if you don't have a composer script that it tries to call.

Right, well checking for a post-root-package-install is one thing, but what about internal starter kits at an agency for instance, that are identical in every way to the official ones, aside from adding a some branding for example, and want the rest of the behavior to stay the same and are using a fork and tracking upstream changes?

then that still works? I'm not sure what you're saying.