[breaking] standardize final output dir as /build (vs /.svelte-kit) #2109
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Background
We changed the output location to
.svelte-kit
yesterday because that directory was in the default.gitignore
and we had gotten numerous requests that an adapter's output should be ignored without need to take user action. It turned out that standardizing under.svelte-kit
has been an unpopular change. Instead we will addbuild
to the default.gitignore
alongside.svelte-kit
and standardize on writing the final output there with intermediate output going to.svelte-kit
Multi-cloud
For the past 24 hours output has been written in a namespaced manner. The consensus on this seems to be that a more deeply nested output location is a worse experience for the majority of users. Adapters will now be standardized to writing in a non-namespaced manner. If users would like two build with two or more adapters, they can either clear out the
build
directory between builds or change the default output location using adapter options to set namespaced build directoriesApologies
We're very sorry for the churn this has caused. Changing the output location is a breaking change and breaking changes are a bad user experience, but two breaking changes in a row on the same feature is especially bad. We have added a new "breaking change" label on Github and made it hot pink to stand out. We will label breaking PRs with this in the future and leave them open for a longer comment period to gather more feedback. However, this PR will be merged quickly as we're aiming to get this PR in before too many people update their projects so that most people will be unaffected. For people that updated their projects in the past 24 hours, we're very sorry for the two breaking changes in a row. This will not change again. We've got only a couple dozen open issues left before 1.0 and at that point will be able to follow semver