Automatically add config changes when generating files

[thefrana]

Hi,

We have found that when generating files using the Sly CLI tool, we often need to manually add some lines to certain configuration files. However, we believe that these configuration changes should also be automatically generated by Sly to streamline the process.

For example, when we generate an email provider using the Sly CLI, we would like Sly to automatically add the necessary environment variables to the .env.example file and update the environment validation schema accordingly.

Could you please let us know if it's possible to enhance Sly to automatically generate these configuration changes when generating files? This would greatly improve our workflow and reduce the need for manual modifications.

Thank you

[jacobparis]

I like this idea a lot, as it would instantly open the door for installing more complicated features rather than just bundles of single files

it is technically quite challenging though to support in a general first party manner.

With the .env idea in mind, we'd need a format that could locate the file, check to see if the variable already exists, and if not apply the default variable. The validation schema is a much harder problem, as it's less likely to be in a standardized location and format.

Updating the file itself could be made easier if Sly supported applying unified diffs, which would also allow for updating components that have had upstream changes, so that's on the wishlist anyway. But the hard part is creating the diff in a way that's useful to most projects

If we assume the right implementation is at the project level, then this can currently be handled in userland by a postinstall script set in the sly.json file. You could write a script that checks the .env.example and writes the new variable, and then inserts text into the config file using a marker comment (example using t3-env here)

export const env = createEnv({
  server: {
    COERCED_BOOLEAN: z
      .string()
      .transform((s) => s !== "false" && s !== "0"),
 
    ONLY_BOOLEAN: z
      .string()
      .refine((s) => s === "true" || s === "false")
      .transform((s) => s === "true"),

-  /* SLY ENTRYPOINT */
+  NEW_SLY_VAR: z.string(),
+ 
+  /* SLY ENTRYPOINT */   
  },
  // ...
});

Another option would be to have Sly use an LLM to read the file tree and suggest file changes, which would open many doors but be quite an investment into making that resilient. We'd need a way to review changes before applying them, though maybe if it creates a new branch and stages changes, the IDE has all the tools it needs to already