houdini

houdini copied to clipboard

I'm currently reading https://www.houdinigraphql.com/api/config and I can't seem to find the field that changes the path or name of the $houdini folder.

It's not currently possible to change that path but I would gladly review a PR that adds a runtimePath option if you wanted to give it a shot. We also will want to add another config value for customizing the alias that the generator uses to import things, maybe something like runtimeAlias?

I have never worked or contributed on a npm repo before so if I did it would be my first time. Also I think this is where the $houdini folder comes from.

https://github.com/HoudiniGraphql/houdini/blob/6e717629e0059cead070a92db9a6b81c91a163d2/src/common/config.ts#L154-L157

A lot places in the source code uses the rootDir. I'm not sure what you mean by runtimeAlias. Do you mean the alias for each import on generated files like import stuff from customAlias?

Also to note, it doesn't seem like the rootDir in the config is exposed in the houdini.config.js file. Or the vsode intellisense doesn't recognize it?

@AlecAivazis is there any reason the $houdini folder is created in the project root? If it could be placed anywhere in the src dir we can skip configuring vite to serve the root directory.

https://github.com/HoudiniGraphql/houdini/blob/70f9f71065767075de037b9dd4ac190101588037/example/svelte.config.js#L25

@Nukiloco That's no problem at all! If you are up for it, I'll help you any way I can. Basically there are two parts to this feature. One part is where the actual ./$houdini directory is written. The actual import resolves using a vite alias so we can leave it up to the user to make sure that $houdini resolves to the custom place they have set. The second part of this feature is the actual text for the alias to use. A user might want to change this to $lib/houdini for example if they don't want to have extra alias in their config and they want to take advantage of the existing $lib alias that SvelteKit. This was a lot of info so feel free to reach out to me on discord if you want a more direct way of talking.

@david-plugge the convention of putting it in root pre-dates SvelteKit requiring the extra vite config to resolve the import. I think the best solution to this problem is to change the way users install houdini to use a SvelteKit/Vite plugin which should let us do the ugly allow stuff behind the scenes

After reading this, I'm still confused on why there would be two config options here instead of one which should just be a path.

Unforuntately we can't have one path that works in both situations because the file system is only accessible through vite aliases ($lib only resolves to ./src/lib because it has been explicitly set up). This means that if we want to be able to support any situation we need to let the user customize both sides of the problem: the actual filepath where things end up and the alias that can be used to import that path. This let's someone configure their setup however they want as long as they are willing to own the alias definition

it may work:

// houdini.config.js
/** @type {import('houdini').ConfigFile} \*/
const config = {
	runtimePath: './src/houdini',
	...
};
export default config;

// svelte.config.js
import houdiniConfig from './houdini.config.js'

/** @type {import('@sveltejs/kit').Config} */
const config = {
	preprocess: [
		preprocess(),
		houdini(houdiniConfig)
	],
	kit: {
		alias: houdiniConfig.runtimePath
	}
};
export default config;

That way we could even pass the config to the preprocessor without having to specify the config path (#395)

additionally, customizing GQL_ would be nice, some projects have case conventions.

You mean to have it lowercase? Or being able to customize "what you want"? 👀

maybe a format string? an option with prefix and case would be good enough

prefix_query_title in snake_case PREFIX_QUERY_TITLE in MACRO_CASE prefixQueryTitle in camel PrefixQueryTitle in Pascal (these two would be the same if prefix was ignored by the case-transformer prefixquerytitle in flatcase (don't think this is necessary)

would fit into

{
    prefix: string,
    case: "camel" | "snake" | "pascal" | "spinal" ... etc
}

prefix_query_title in snake_case

PREFIX_QUERY_TITLE in MACRO_CASE

prefixQueryTitle in camel

PrefixQueryTitle in Pascal (these two would be the same if prefix was ignored by the case-transformer

prefixquerytitle in flatcase (don't think this is necessary)

Would it be crazy to use the examples as the pattern? At least that way it's more descriptive of what will be generated.

I imagine it'd look something like:

{
    pattern: "QueryName",
    // or
    pattern: "GQL_Query_Name"
}

Isn´t it sufficient to just add a prefix config option? I´m not sure but is the name is extracted from the Graphql query/mutation... ? If so the prefix should be enough right?

Isn´t it sufficient to just add a prefix config option? I´m not sure but is the name is extracted from the Graphql query/mutation... ? If so the prefix should be enough right?

not sure how this works internally, if the query portion is derived from the query text then yeah just prefix would be good

Now that the #460 tangent is closed, is this planned as well?