Closed manuel3108 closed 3 weeks ago
Latest commit: 59666a945d1d778b23f87a4b0c7e9e39623ab918
The changes in this PR will be included in the next version bump.
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
we can remove the svelte
environment now as this was the only one that wouldn't run in a kit project
Do you mean completely removing the svelte
property, or completely removing the environment
property?
But that's actually not true, tailwindcss
can still be added to a svelte
project in example
We can just have the kit
field where it indicates that SvelteKit is required. if kit === true
and we're not in a SvelteKit project, then the precondition error is thrown.
In the case of tailwind
, kit
will be false
, so it should work in all places
Should this still be an object while we are going to be refactoring that? Can we think of any other environments
that might appear in the future?
Should we rename kit
to requiresKit
to make things more clear?
Maybe we should just get rid of the field entirely and add a setup
hook as part of #181? I don't think we should be blocking this PR from merging as we can address this separately.
Yeah, I was talking about the svelte
environment, which has always felt weird to me because everything is a svelte project. Maybe we should just rename that one to vite
instead?
Can we think of any other environments that might appear in the future?
vite
would probably be the main one. Like I bet the Tailwind adder isn't actually a svelte
adder, but is a vite
adder. Probably if you tried to set it up in a webpack project it doesn't work because you need postcss setup correctly
yeah, it doesn't have to block this PR
I'd thought about the setup hook too. The trade-off there is that a hook is more flexible, but can't be displayed easily via a website directory
But kit
project are also using vite
.
setup
hooks sounds fine, and aligns with our goal of a more flexible api. But let's implement this in #181
As we decided to ditch #32 for an upcoming more flexible PR, we should remove routify separately. Reasoning: Routify is nearly unused on npm, and we do recommend creating full kit applications