feat: prompt user to install Japa and its AdonisJS preset #44
Conversation
| Should we have |
| Totally agree ! Done |
| Btw, I would also be in favor to have a "yes" by default on the installation of prettier and eslint, but it's another subject |
| Do we really want to do this? What is the alternative to Japa right now when it comes to testing AdonisJS apps? If you use Jest, you cannot go too far, because there will be no helpers to login users during HTTP requests, no helpers to easily migrate/rollback database. |
| It should be possible to use TestUtils from another test runner, no? For Auth on the other hand it seems more complicated because it depends on Japa. But the user should be able to create his own helpers to facilitate his tests or it is simply impossible? |
It's possible. But no one has done it so far, so I am not sure what are we optimizing for, by making the Japa test runner optional. If someone comes with a good Jest implementation, then yes we can make it optional. But right now, we are doing it just for the sake of modularity. Now someone might ask, well what's the issue in being modular? |
| Here is a small proposal. I think discuss it in long term too (if required)
Again, the reason others use AdonisJS because it comes with everything you need to build an end to end application. And minimalists anyways drop off and use express or something similar |
| Okay, I understand and I even agree. I also agree to integrate lucid and auth by default. But I think that, more widely, it is worth discussing my proposal here: #43 IMO, the best solution would probably be to propose the installation of these packages during create-adonis-ts-app. In my case, most of my AdonisJS applications use mailer/lucid/auth/Redis/drive. I like this full-featured side of AdonisJS, and it would be great to have all the tools I need in one command line. |
Yup, I agree. We can have a default set of packages and then additional one's can be configured with CLI flags. Let's see if @RomainLanz has something else in mind that we cannot see. My take is to make the initial boilerplates even more opinionated vs making them modular. |
| @thetutlage I would say you have somewhat of a point for now, but we have already been using our own custom runners (using just japa/core) If the runner can at least be dropped from the Personally, I was drawn to AdonisJS since it isn't as opinionated as Laravel and with much less boilerplate. |
| Sorry for the late reply. I like the idea to be able to customize the application the way we want during the scaffolding process. IMO, removing it from default installation is the way to go. We stay opinionated and modular, we don't force people to use our module, we give them the opportunity to use whatever they want. |
This will hamper the experience for the once that needs a fully featured scaffold by default (that is the majority of users). Just making them answer 7-8 prompts. I will keep the |
| We could keep the three default boilerplates and add a "custom" next to them? When the user selects "custom" instead of "web/api/slim" then at that point we do prompts the user what they want to install? |
I am not sure about that, but if it is a concern, we could add a |
Trust me, if we do a poll today, then 90% will be in the favor of just install Infact, we can drop |
Not a bad idea |
| But I agree; when people select a boilerplate, it looks like everything should be set up, and no question should be asked. Now the question would be: what happened with I like the idea of having a |
Yeah, these are tricky one's and I think I have some reasoning behind them (atleast I have told this to myself :) ) Prettier and EsLint both are not part of the framework, so if I don't use the settings suggested by the framework, then it is very easy for me to install them afterwards with my own/team settings. Also, here the chances of using our defaults are low. If, I am part of a team, I will prefer to use the team settings. Regarding Encore. Yes, let's install it by default. One less question to answer |
| So, to recap:
The three boilerplate ask the user if he wants to install eslint /prettier That are going to be a lot of prompts for the custom version, but personally, I'm totally okay with that, and that will be my default choice for all my future applications because I will not have to do Now I'm not sure I understand the interest in the |
I am not sure it would be useful with the The goal of that flag would be to customize the selected boilerplate, but we can forget about it for the moment. |
| @Julien-R44 Yup, I am onboard with the choices |
| Instead of having a |
For the slim boilerplate? |
Yes, for the |
| Yup. That does make sense |
| Ok cool guys, thanks ! |
Proposed changes
As proposed here : adonisjs/core#3709
Types of changes
What types of changes does your code introduce?
Put an
xin the boxes that apply