svelte-preprocess VS houdini

You can learn more about the official svelte-preprocess and other available config here

svelte-preprocess is responsible for processing things like TypeScript and SCSS. The svelte compiler itself is only responsible for turning the svelte file into JavaScript.

svelte-preprocess should handle scss out-of-the-box, and it’s included in SvelteKit by default if you created your project with create-svelte

// svelte.config.js import sveltePreprocess from 'svelte-preprocess' export default { // Consult https://github.com/sveltejs/svelte-preprocess // for more information about preprocessors // **here -> postcss: true** preprocess: sveltePreprocess({ postcss: true, }) }

/** @type {import('@sveltejs/kit').Config} */ const config = { // Consult https://github.com/sveltejs/svelte-preprocess // for more information about preprocessors preprocess: preprocess({ typescript: true, postcss: true, scss: { prependData: @import 'src/styles/helpers/functions.scss'; } }), kit: { paths: { assets: '', base: dev ? '' : '/route/in/website' }, trailingSlash: 'always', adapter: adapter({ pages: 'build', assets: 'build', fallback: 'index.html' }), files: { hooks: 'src/hooks', }, prerender: { default: true, }, } };

Continue to use tags

In svelte.config.js ... (import aliases can be whatever you want)

1. import svelte_preprocess from 'svelte-preprocess'
2. import autoprefixer from 'autoprefixer'
3. pass the Svelte preprocessor to Kit's preprocess config option and pass the postcss plugin to that Svelte preprocessor:

svelte.config.js

import svelte_proprocess from 'svelte-process'
import autoprefixer from 'autoprefixer'

const config = {
    // Consult https://github.com/sveltejs/svelte-preprocess for more info
    preprocess: [
        svelte_preprocess({
            postcss: {
                plugins: [autoprefixer()]
            }
        })
    ]
}

import adapter from '@sveltejs/adapter-auto'; import preprocess from 'svelte-preprocess'; import { mdsvex } from 'mdsvex'; import remarkMath from 'remark-math'; import rehypeKatex from 'rehype-katex-svelte'; /** @type {import('@sveltejs/kit').Config} */ const config = { extensions: ['.svelte', '.svx', '.md'], // Consult https://github.com/sveltejs/svelte-preprocess // for more information about preprocessors preprocess: [ preprocess(), mdsvex({ extensions: ['.svx', '.md'], smartypants: true, layout: { project: "./src/routes/projects/layout.svelte", post: "./src/routes/blog/layout.svelte", }, remarkPlugins: [remarkMath], rehypePlugins: [rehypeKatex], }), ], kit: { adapter: adapter({ edge: false, external: [], split: false }) } }; export default config;

Have you tried https://github.com/sveltejs/svelte-preprocess

// We have changed the adapter line to use adapter-node@next import adapter from '@sveltejs/adapter-node@next'; import preprocess from 'svelte-preprocess'; /** @type {import('@sveltejs/kit').Config} */ const config = { // Consult https://github.com/sveltejs/svelte-preprocess // for more information about preprocessors preprocess: preprocess(), kit: { // We have changed this to point to a build directory adapter: adapter({ out: 'build' }) } }; export default config;

Other random input. Maybe take a look at houdini. https://github.com/HoudiniGraphql/houdini

Full disclosure: I'm the author of KitQL & maintainer of Houdini I've been in the GraphQL ecosystem for a long time and love it. I discovered Svelte early 3.0 and directly opt-in SvelteKit at the very beginning. I've tried different approaches with codegen Apollo & urql. Helping developing graphql-codegen-svelte-apollo at first then urql-svelte-operations-store. Contributing / creating / maintaining open source is something I like to do to build a friendly community around similar stacks. Then gQuery came out and took a radical new approach to things in a great way. I was hyped about it, especially for the simplicity and SSR out of the box. I believe that multiple projects bring new ideas to the community, which is awesome. It's here that I created KitQL to unlock some options that I need for my customers (Yes, I don't do only open source ^^). My aim with KitQL is to focus on two things: 1/ Embrace the community. To build something with others that satisfies many use cases. 2/ Build a full stack GraphQL on SvelteKit. Client + Server, using all powerful tools from The Guild. Thx to the community; we get to speak with amazing people, and I got the chance to talk with the Houdini author. After a few conversations, we decided to join forces. KitQL Client had a few issues that will be complicated to solve: no normalized cache, prefetch cannot work, leaks in SSR... to name a few. So I deleted KitQL Client in favor of using Houdini. KitQL is now focused on the backend part and module development (but it's not the topic here). Houdini has significantly evolved in the last months to bring KitQL flow inside + keep all its benefits! I think that it has a unique DX matching a lot of different styles of programming. You want your GraphQL operations in a separate file? Inside your Svelte componennt? You want Houdini to generate some boilerplate to focus only on your business logic? You want Houdini to create magic fragments to insert into a list automatically after a mutation? Houdini got you covered! And you know what? With the new '+page.svelte' directory structure, Houdini will go to another level!!! In a few days, we will merge a PR that will improve even more the DX and will be sooo integrated with the new SvelteKit changes. //I'm so excited about it. Come and check #BuildInPublic https://github.com/HoudiniGraphQL/houdini As you could read, the most important is the community, so thank you!

Repository

So, you've decided to build an application with two of the most hyped projects in our community (SvelteKit and GraphQL, in case you didn't read the title). After browsing the internet for a bit, you've probably ran into various posts showing how to send a query in Kit's load and use it to populate the cache driving one of the more common GraphQL libraries. If you're like me, it probably left you with a bit of an unsatisfying feeling. GraphQL was supposed to reduce the amount of boilerplate necessary to build a user interface, right? Surely there's a way to pull this off without all that ceremony. Well, in this blog post I'll introduce you to houdini, a new GraphQL client I've been working on that's built for SvelteKit. Hopefully by the end of this you'll agree that it dramatically reduces the overhead of building a GraphQL application with SvelteKit.