Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Explain 'preconditions' in docs #240

Open
Rich-Harris opened this issue Oct 28, 2024 · 5 comments
Open

Explain 'preconditions' in docs #240

Rich-Harris opened this issue Oct 28, 2024 · 5 comments

Comments

@Rich-Harris
Copy link
Member

The sv-add docs list the --no-preconditions option but with no clue as to what preconditions are and why I'd want to disable them (and when it would be safe to do so)

Better still would be to get rid of the option altogether in my view — either they're preconditions (in which case you can't disable them without breaking stuff) or they're not

@benmccann
Copy link
Member

The current preconditions is a check to see if you have a dirty git repo

Theoretically community adders could add more, but I'd like to avoid adding API surface area until necessary

Perhaps we can just have a standalone option for checking if you have a dirty working directory

@manuel3108
Copy link
Member

There is also a precondition to check that you don't apply a "svelte" adder to a "kit" project. And the other way around of course. But that could easily be abstracted away.

The cli offers you to skip the preconditions, which is why this flag exists.

Not arguing for or against it here, just explaining.

@benmccann
Copy link
Member

the concept of a "svelte"-only adder is about to go away with the PR removing routify

@manuel3108
Copy link
Member

But we will still need to extract that logic into somewhere, as people could still try adding drizzle to "svelte" (we all know that this does not make sense, but people have crazy ideas)

@benmccann
Copy link
Member

yeah, we'd still have the kit precondition. but I'm not sure it makes sense to have an option to skip that one. so an option specific to git probably makes sense

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants