Required files aren't automatically created (package.json, local.settings.json)

[FlippingBinary]

Currently, the adapter throws an error if api/package.json doesn't exist.

Also, SWA reports errors if local.settings.json does not exist or does not have a valid FUNCTIONS_WORKER_RUNTIME value (see documentation). In order to suppress this error, api/local.settings.json can be created with this content (see Azure/azure-functions-core-tools#2050 (comment)):

{
  "IsEncrypted": false,
  "Values": {
    "FUNCTIONS_WORKER_RUNTIME": "node"
  }
}

This isn't mandatory, as it runs just fine without it, but the errors are annoying:

[api] Can't determine project language from files. Please use one of [--csharp, --javascript, --typescript, --java, --python, --powershell, --custom]
[api] Can't determine project language from files. Please use one of [--csharp, --javascript, --typescript, --java, --python, --powershell, --custom]
[api] Can't determine project language from files. Please use one of [--csharp, --javascript, --typescript, --java, --python, --powershell, --custom]

It would be easier on people who are new to this adapter if these files were automatically created when they are absent.

[geoffrich]

If I recall correctly, the api/package.json can't be auto-generated - it needs to be in the repo at build time, otherwise the GitHub action will use the wrong Node version. So auto-generating won't help, because it won't show up until the SvelteKit build starts, at which point it's too late.

Re: api/local.settings.json - I don't think that makes sense to auto generate either, since it only makes sense at dev time and would be one more thing to gitignore. When do you see this error? Could we document the need for this file in the README instead?

[FlippingBinary]

I tried testing it in a GitHub action with no api/packages.json but Oryx (Microsoft's build system) correctly reports detecting nodejs 16.14.2, so that's what it installs to use. The packages.json of my app has a section like this:

	"engines": {
		"npm": ">=8.7.0 < 9",
		"node": ">=16.14.0 < 17"
	},

The version Oryx picked up is in that range, although I don't know for sure if it used that file to detect the version. Either way, it doesn't seem to have a problem until this adapter throws an error for the missing file.

I might work on #69 so I can test a few things in an Azure deployment and maybe gain a better understanding of how the GitHub action works.

Ultimately, I think it would be cleaner if api was inside /build by default and could be overridden as requested in #42 with any configuration files like local.settings.json and host.json being automatically generated with safe defaults inside /build/api or copied/merged from the root directory, if they already exist. The default .gitignore of a new SvelteKit project already includes the /build directory, so automatically generated files in there would not be committed.

However, I don't know how the GitHub action gets automatically generated and if there is a way to ensure it sets api_location to build/api (or a configured alternative) instead of api. That is something I will have to test.

[geoffrich]

However, I don't know how the GitHub action gets automatically generated and if there is a way to ensure it sets api_location to build/api (or a configured alternative) instead of api.

For the GitHub action, you just set the API location: https://github.com/geoffrich/svelte-adapter-azure-swa#azure-configuration

I agree that moving api inside build would be a lot cleaner. I think when I originally wrote the adapter, the build failed if the API folder wasn't in source control when the build started. If we can get rid of the clunky setup instructions where you have to create an api folder with host.json and package.json and auto-generate those files instead, that would be ideal.

It seems like the recently released Nuxt 3 integration does output the Azure function into an output directory, so maybe this is possible now?

In the Api location, enter .output/server in the box.

We may be able to take inspiration from this code that controls the output.

[geoffrich]

I'm also not sure what the implications of solving #42 would be, so I think it would be best if supporting that feature was in a separate PR to auto-generating the files.

[FlippingBinary]

If Nuxt 3 is doing it, I've got hope that it's possible! I'm glad you found out about that. The code you referenced looks almost exactly like what I was going to do, except with a different path resolver and async write instead of sync write. The trick is going to be in making sure Microsoft's builder does what it needs to do before the adapter gets involved. I tested it in the branch I made for #69 and confirmed their builder defaults to node 14 if engines is not set like I described above, so I suspect it's going to involve usage instructions describing that. I'll look into Nuxt 3 and see what I can learn from their approach.

[geoffrich]

Okay, so it looks like this is definitely possible now! Started the work in #92 and it seems to work in the demo preview. Would appreciate some feedback on the approach if you have any.