[harmony7]

Summary

This PR fixes three bugs in the scaffolder, and deprecates --public-dir and server.publicDirPrefix.

publicDirPrefix was always empty

If --public-dir is under --root-dir, the scaffolder must set server.publicDirPrefix to the path of the public directory, relative to the root directory (for example /public). The code sliced rootDir and not publicDir, so the value was always ''.

publish-content makes the asset keys relative to the root directory (for example /public/index.html). The server looks up publicDirPrefix + pathname (/index.html). Thus the server returned 404 for all requests.

The server already uses staticItems relative to the public directory, and spaFile and notFoundPageFile as asset keys. These values are correct, and they do not change.

The v7 branch has the same bug. I will port the fix to v7 after this PR merges.

Deprecate --public-dir

v4.0.0 separated --root-dir and --public-dir for module assets: files under the root dir but not under the public dir were published, but requests could not get them. This package no longer supports module assets. The scaffolder bug above was in the first commit of this change, so --public-dir under --root-dir did not work in any version from v4 to v8.

This PR marks --public-dir as deprecated in the help text and in the CLI options section of README.md, and the scaffolder shows a warning if it is used. A future version will remove it.

server.publicDirPrefix exists only for this option, so it is deprecated too:

• PublisherServerConfig.publicDirPrefix has a @deprecated tag.
• publish-content shows a warning if the setting is not empty.
• The scaffolder writes the setting only if it is not empty, that is, only with --public-dir.
• The server still uses the setting, because collections that are in storage can have it.

#101 marks the setting as deprecated in README.md.

MIGRATING.md has a new section in the v7 to v8 guide, "Stop using publicDirPrefix (deprecated)", with the steps to move the files and change publish-content.config.js. The CHANGELOG entry and the publish-content warning refer to it.

Closing instructions referred to a script that does not exist

The scaffolder showed npm run fastly:start at the end. The scaffolded package.json does not have this script. The instructions now show npm run fastly:deploy. For the KV Store, they show fastly:deploy before fastly:publish, because the deploy creates the KV Store. This is the same order as the README.

S3: the Secret Store keys in fastly.toml were ignored

The scaffolder declared the keys of the S3_CREDENTIALS Secret Store under [setup.secret_stores.S3_CREDENTIALS.items.*]. The Fastly CLI reads them only from entries (see SetupSecretStore in pkg/manifest/setup.go of the Fastly CLI). Thus, on the first deploy, the CLI created and linked a Secret Store with no keys, and it did not prompt for the credentials. The server then could not read from the bucket. The v7 branch does not have S3 support, so it does not have this bug.

The closing instructions also told the user to create the Secret Store before the deploy. With [setup] working, the first deploy then finds a store with that name and asks for a different name. Now the instructions say that the first deploy prompts for the values, and that an existing service needs the Secret Store before the deploy.

Tests

• New end-to-end test in test/e2e/local.test.js: it scaffolds with --root-dir ./site --public-dir ./site/public, publishes with --local, and runs checkServedContent(). Without the fix, 9 of 13 tests fail (404). With the fix, all pass.
• scaffoldApp() has a new rootDir option (default ./public).
• New end-to-end test test/e2e/scaffold-s3.test.js: it scaffolds an S3 app and checks the [setup] section of fastly.toml. It needs no credentials. It fails without the fix.
• I did not do a real first deploy, because it creates a new Fastly service. The prompt behavior comes from the Fastly CLI source (pkg/commands/compute/setup/secret_store.go).
• test/e2e/local.test.js also checks that a default scaffold does not write publicDirPrefix.
• Checked both deprecation warnings and the generated config by hand.
• Did steps 2 and 4 of the migration on a scaffolded app with --local: the new index has /index.html, the stored publicDirPrefix is "", and publish-content shows no warning.
• npm test: 72 pass.

🤖 Generated with Claude Code

[kpfleming]

The second sentence of this comment is misleading; it described the situation before this PR, for an example in the setup guide. It should not be here. Please be more careful when reviewing LLM-generated code and in particular tell the LLM to never generate code comments which describe why a change was made or how the code worked before it was changed. These comments are not useful and could be misleading.

[kpfleming]

This is not appropriate to fix in this PR, but all of the references to/discussion of Secret Store naming in this section (and possibly other places) are wrong. The name of the Secret Store is not relevant except in local testing; in production, what matters is the name of the resource link which connects the Compute service to the Secret Store. While those names can be the same, they are not required to be the same, and a user should be informed about the existence of both names and understand that they do not need to name their Secret Store S3_CREDENTIALS (doing so in a CID with lots of services and Secret Stores would result in a name which doesn't provide sufficient meaning to know what it is used for).

[kpfleming]

In a future update to the CLI, the setup and local_server sections should make this apparent by having resource_links, but that's also a topic for elsewhere.

[harmony7]

I'm going to fix the wording where I can here in this PR because it has to do with S3 Secret Store setup, and this is a new feature for v8.

[kpfleming]

Looks great!