feat(add): drizzle add-on can now create multiple configs

[jycouet]

Closes: #701

---

When it's the case, I added a line in Next steps

Let me know what do you think.

[changeset-bot]

🦋 Changeset detected

Latest commit: fdf52b8

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
sv	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[pkg-pr-new]

Open in StackBlitz

npx https://pkg.pr.new/sveltejs/cli/sv@704

npx https://pkg.pr.new/sveltejs/cli/svelte-migrate@704

commit: fdf52b8

[manuel3108]

Ohh, missed the PR. Why not override the existing files? I think the other addons are doing this as well, arent they?

[jycouet]

I think that is you add drizzle in a project with already drizzle you probably want to add another flavor.
And you probably have a lot of tables already... So I think that it's better to add "new" if we detect an existing file.

[manuel3108]

I think this would be really inconsistent with the other addons that we support. That's why i find it hard debating on it, even if I totally understand your point of view.

[jycouet]

The problem is that we have both valid points 😁

In all other add-ons, it would be strange to create another config/setup. So if files exists we try to augment them with the add-on. eg1: eslint adding our reco.
eg2: vitest, If you run it 2 times, and select 2 times unit, it would be strange to have src/demo.spec.ts and src/demo.spec-2.ts

To write this I'm looking at the code and find that it's not fully consistent as well. For example, in vitest, if there is already src/demo.spec.ts we don't add the demo test in the file, we skip adding the test. I think it's OK like this

The closer case to drizzle for me would be paraglide where I could imagine to run it multiple times. First time with en, es and second time with fr for exemple. (Just did the test RN, we half support this case ^^)

---

All in all, I think that it's quite "case by case", or "what make sense". In ORMs, I already had to deal with multiple dbs, that's why I think that it could make sense But also, tbf, it's not in majority of my projects!

Here, there are 2 options:

• Add multiple configs (this PR)
• Skip file editing if it exists (like vitest) + explain in next step.

In the 2 options, we have to fix the -C thing.

[benmccann]

We could say something like "we've detected an existing config file. Would you like to update the existing one, skip, or create a new one?"

[jycouet]

Update an existing one is not really an option IMO. If you already have a schema, it would not make a lot of sense to change to ours.
And additionnal question is always good to avoid.

Maybe, to be closer to today, we could just craft a better "next step". So, not create a new db, but explain what to change to be able to relaunch cli to create a new db ?

This PR is doing

• if "db" then "db-2". But we know that "db-2" will never be a good name when you have 2 db. (and I would like to avoid the question "what name do you want ?)
• so it's maybe better to say in next step: "db" already exist, if you want to create a second db, rename your existing one to something else meaning full to your app !

[benmccann]

I think it's just such an uncommon thing to run the adder a second time, that it's very hard to predict what the user is trying to accomplish. Some of the other adders try to fix the existing setup, but it seems so error prone and impossible to predict in what way things might be broken that I often think we'd be better off not even trying. I guess here there is some legitimate reason to add a second database, so I'm not opposed to it. It's pretty uncommon, so I don't know that I would have invested the effort, but I don't see any harm in it either

maybe better to say in next step: "db" already exist, if you want to create a second db, rename your existing one to something else meaning full to your app !

They might not want to if the existing one is their main db. In that case calling it db is fine. The second one might be some secondary db. I think it'd be fine to either give it a temporary name or ask them what to name it. If we asked what to call it then it would give us a way to update the existing one of they picked the same name as the existing one

[jycouet]

I see:

I don't see any harm in it either

it'd be fine to either give it a temporary name

That's this PR :D

[jycouet]

After gathering feedback from several people (including some IRL chats 😄), it looks like this feature isn’t quite as 50/50 as I initially thought.
Seems like I’m a bit on the lonely side, and that’s totally fine. I like to be different 😊

So I’ll go ahead and close this one in favor of the simpler fix: #738

Thanks everyone for inputs! 🙏
Happy coding