feat: generate types for runtime config

[BlankParticle]

🔗 Linked issue

#1706

❓ Type of change

• 📖 Documentation (updates to the documentation, readme, or JSdoc annotations)
• 🐞 Bug fix (a non-breaking change that fixes an issue)
• 👌 Enhancement (improving an existing functionality like performance)
• ✨ New feature (a non-breaking change that adds functionality)
• 🧹 Chore (updates to the build process or auxiliary tools and libraries)
• ⚠️ Breaking change (fix or feature that would cause existing functionality to change)

📚 Description

I have add untyped as a dependency and now nitro can generate types for useRuntimeConfig() just like Nuxt does.
It would be helpful for users to have types for useRuntimeConfig() which helps a lot while using nitro standalone.

For now I have utilized nitro-config.d.ts to keep the types in, please let me know If you would want to change the file.

Fixes #1706

📝 Checklist

• I have linked an issue or discussion.
• I have updated the documentation accordingly.

[danielroe]

It would maybe be nice to allow this to be disabled, in case there's an issue with types conflicting between auto-generated nuxt + nitro types.

[BlankParticle]

It would maybe be nice to allow this to be disabled, in case there's an issue with types conflicting between auto-generated nuxt + nitro types.

I was thinking about that, but what condition do I check against to disable it?

[danielroe]

You would add a nitro option:

nitro/src/options.ts

Lines 121 to 128 in d12aae1

	// Advanced
	typescript: {
	strict: false,
	generateTsConfig: true,
	tsconfigPath: "types/tsconfig.json",
	internalPaths: false,
	tsConfig: {},
	},

[pi0]

in case there's an issue with types conflicting between auto-generated nuxt + nitro types.

We can disable when framework usage is detected. What inconsistency can happen?

[danielroe]

Ideally we wouldn't disable - just wanted a way to bail out if there was an issue. Sometimes if you have multiple augmentations of the same underlying property there can be failure, and I haven't yet tested this implementation. (Which might be a better first step! 😆)

[danielroe]

Might be nice to add a type test to the fixture to verify that these types do in fact type the runtimeConfig. 🙏

[BlankParticle]

Might be nice to add a type test to the fixture to verify that these types do in fact type the runtimeConfig. 🙏

Ok, I will add tests too
Edit: I just checked out the tests and it looks like all tests call a given nitro api endpoint to test against.
How do you want me to test this?

[BlankParticle]

I was looking into test the types but I don't see a good way to do so, any suggestions?