Skip to content

feat: adapter features, deprecate astro configs#7839

Merged
ematipico merged 3 commits intonextfrom
feat/adapter-features-plt-733
Jul 28, 2023
Merged

feat: adapter features, deprecate astro configs#7839
ematipico merged 3 commits intonextfrom
feat/adapter-features-plt-733

Conversation

@ematipico
Copy link
Copy Markdown
Member

Changes

This PR deprecates build.split and build.excludeMiddleware.

After an internal discussion, we realised that these two config values should not live inside Astro, because they are only usable only with an adapter that can understand it

Because of that, we introduced the concept of adapterFeatures. These features are toggles that signal Astro to change the output of the build, and then the adapter needs to do something with those.

Testing

I updated the current test to use the new configuration. The tests should pass.

Docs

/cc @withastro/maintainers-docs for feedback!

@ematipico ematipico requested a review from a team as a code owner July 27, 2023 13:59
@changeset-bot
Copy link
Copy Markdown

changeset-bot bot commented Jul 27, 2023

🦋 Changeset detected

Latest commit: af251d9

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

@github-actions github-actions bot added pkg: integration Related to any renderer integration (scope) pkg: astro Related to the core `astro` package (scope) labels Jul 27, 2023
Copy link
Copy Markdown
Member

@bluwy bluwy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for making the changes! This looks great to me.

Should we also validate if the deprecated configs are used in runtime, somewhere around here?

let legacyConfigKey: string | undefined;
for (const key of Object.keys(userConfig)) {
if (LEGACY_ASTRO_CONFIG_KEYS.has(key)) {
legacyConfigKey = key;
break;
}
}
if (legacyConfigKey) {
throw new AstroError({
...AstroErrorData.ConfigLegacyKey,
message: AstroErrorData.ConfigLegacyKey.message(legacyConfigKey),
});
}

Also, the docs team were also interested in the API discussion for this, so might be good to run by them if this new syntax is better. cc @withastro/maintainers-docs

@ematipico
Copy link
Copy Markdown
Member Author

@bluwy

Should we also validate if the deprecated configs are used in runtime, somewhere around here?

Two reasons why we can't do that:

  • these keys throw an error, which means it won't be a deprecation;
  • the code reads only the first level of keys, which doesn't fit our case because both keys are inside build

@ematipico ematipico force-pushed the feat/adapter-features-plt-733 branch from 38d243f to baffd37 Compare July 28, 2023 08:31
@ematipico ematipico merged commit 4232be5 into next Jul 28, 2023
@ematipico ematipico deleted the feat/adapter-features-plt-733 branch July 28, 2023 09:11
Copy link
Copy Markdown
Member

@TheOtterlord TheOtterlord left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not core docs, but I found a few typos


export interface AstroAdapterFeatures {
/**
* Creates and edge function that will communiate with the Astro middleware
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* Creates and edge function that will communiate with the Astro middleware
* Creates an edge function that will communicate with the Astro middleware

// The middleware should not be imported by the pages
if (!opts.settings.config.build.excludeMiddleware) {
if (
// TODO: remover in Astro 4.0
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

typo?

Suggested change
// TODO: remover in Astro 4.0
// TODO: remove in Astro 4.0

@bluwy
Copy link
Copy Markdown
Member

bluwy commented Jul 28, 2023

Two reasons why we can't do that:

  • these keys throw an error, which means it won't be a deprecation;
  • the code reads only the first level of keys, which doesn't fit our case because both keys are inside build

I mean we can to the warning deprecations, and validate build.* around that area of the code, not necessarily error-ing like it. But it would be a nice to have for me and not something needed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

pkg: astro Related to the core `astro` package (scope) pkg: integration Related to any renderer integration (scope)

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants