Amend import order in auth templates according to ESLint rules introduced in v2.0

[Philzen]

No description provided.

[netlify]

✅ Deploy Preview for redwoodjs-docs canceled.

Name	Link
🔨 Latest commit	d4e3b86
🔍 Latest deploy log	https://app.netlify.com/sites/redwoodjs-docs/deploys/62f278e37968b800082faa84

[nx-cloud]

☁️ Nx Cloud Report

CI is running/has finished running commands for commit d4e3b86. As they complete they will appear below. Click to see the status, the terminal output, and the build insights.

📂 See all runs for this branch

---

✅ Successfully ran 14 targets

• cli run test --concurrency 2 -- --colors --maxWorkers 2
• cli run test --concurrency 2 -- --colors --maxWorkers 2
• cli run build
• cli run build
• cli run build
• cli run test --concurrency 2 -- --colors --maxWorkers 2
• cli run test --concurrency 2 -- --colors --maxWorkers 2
• cli run build
• cli run build
• cli run build
• cli run build
• cli run build
• cli run build
• cli run build

---

Sent with 💌 from NxCloud.

[jtoar]

Looks good, thanks again @Philzen!

[jtoar]

This PR changes a setup command, so leaving a quick note to myself to double check the fixtures.

[Philzen]

This PR changes a setup command, so leaving a quick note to myself to double check the fixtures.

While working on #6159 i realized that there are multiple templates that needed import order fixes. I've fixed all of those now. As i'm currently trying to close off any open ends before i go silent for my summer hiatus, just wanted to quickly check back whether the fixtures are OK or anything needs to be done. I'm happy for you to add any necessary changes to this PR otherwise.

---

@jtoar as i am currently peeking into the .github-folder and can see you wrote a lot of the CI configuration (which is an art by itself, but a highly useful one!): the other day i was contemplating about the types of issues i'm seeing and working on, and i believe it's a good dozen now that all come down to the same thing: TypeScript or linting errors in code that is generated via CLI that would easily be detected via yarn rw lint

I can see that there is a linting job in the ci.yml, but i believe we should expand a little bit here. We'd need a smart test suite that executes each and every possible code-generating command (scaffolds, other generators, setup ui, setup auth) etc. on the generated test project, runs yarn rw lint after that on each of the generated files, and then hard resets again to continue with the next command (at least for some of them, i.e. for setup ui and auth it's either one or the other). If any of that comes back with an non-zero exit code, the pipeline would fail and PR authors would immediately know that they need to fix something.

What do you think? Would that be achievable? If you agree, maybe we should formulate an RFC for that.

From what i can see, that would have saved us dozens of individual "cleanup afterwards" PRs – and i can foresee many regressions happen over and over again, e.g. next time we change the ESLint rules, but also on simple changes to some of the more complex generators.

[Tobbe]

@Philzen Thanks for this. This is great. And I've made the same changes to my auth refactor PR #5985

This PR now needs the test project fixtures updated. So either you do that (fixtures/test-project/api/src/lib/auth.ts)
Or we close this PR and wait for my refactor PR to land. You decide :)

[Philzen]

@Philzen Thanks for this. This is great. And I've made the same changes to my auth refactor PR #5985

This PR now needs the test project fixtures updated. So either you do that (fixtures/test-project/api/src/lib/auth.ts) Or we close this PR and wait for my refactor PR to land. You decide :)

@Tobbe I must be too tired / overworked but i'm simply not getting what i'd need to change in __fixtures__/test-project/api/src/lib/auth.ts (the import order seems fine in there), can you give me a hint?

Also, do i understand correctly that this file would also need to be synchronized for #6159 to go through?

As i already invested the effort, i'd of course prefer those to go through and claim the (albeit-so-little) fame 😉 But if you're saying this will create huge rebasing conflicts on your branch, and that is going to land soon (=early enough to ship in v2.3) you may close this.

Otherwise, i'd prefer you pushing the necessary change to this PR directly, enlighten me directly through that, and have those fixes merged and available for any users starting fresh with v2.3.

[Tobbe]

@Tobbe I must be too tired / overworked but i'm simply not getting what i'd need to change in __fixtures__/test-project/api/src/lib/auth.ts (the import order seems fine in there), can you give me a hint?

It's a weird hour for both of us 🙂

The bot isn't smart enough to know if anything actually needs to be updated. It just looks at what files were changed. I've overruled the bot, and have now enabled auto-merge

[Tobbe]

Also, do i understand correctly that this file would also need to be synchronized for #6159 to go through?

Yes, for that one you actually do have to update the fixture

As i already invested the effort, i'd of course prefer those to go through and claim the (albeit-so-little) fame 😉

Fame is well deserved! Of course you should have it

But if you're saying this will create huge rebasing conflicts on your branch, and that is going to land soon (=early enough to ship in v2.3) you may close this.

The next release is most likely going to be a breaking v3.0 release. Hopefully this or next week. I feel like I'm making good progress on the auth refactor, but I can't promise it'll be ready for v3. Especially since we'd need to update the api side too to take full advantage of the changes I'm making. And that work has only been started on an experimental level so far. No ongoing PR.

[Philzen]

@Tobbe While finalizing #6061 i realized the imports in the dbAuth scaffolds were also not yet ordered accordingly and quickly added that on top as a separate commit. Kindly review / re-approve.