Skip to content

stronger dynamic env types #7735

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 5 commits into from
Nov 21, 2022
Merged

stronger dynamic env types #7735

merged 5 commits into from
Nov 21, 2022

Conversation

ignatiusmb
Copy link
Member

Prefixes the dynamic type index signature with config.env.publicPrefix

Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

  • It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
  • This message body should clearly illustrate what problems it solves.
  • Ideally, include a test that fails without this PR but passes with it.

Tests

  • Run the tests with pnpm test and lint the project with pnpm lint and pnpm check

Changesets

  • If your PR makes a change that should be noted in one or more packages' changelogs, generate a changeset by running pnpm changeset and following the prompts. All changesets should be patch until SvelteKit 1.0

@changeset-bot
Copy link

changeset-bot bot commented Nov 21, 2022

🦋 Changeset detected

Latest commit: 39552e8

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

This PR includes changesets to release 1 package
Name Type
@sveltejs/kit Patch

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

Copy link
Member

@dummdidumm dummdidumm left a comment

Choose a reason for hiding this comment

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

Does this mean that so far the public dynamic types were all wrong?

.filter((k) => valid_identifier.test(k))
.map((k) => `\t\t${k}: string;`);

properties.push(`\t\t[key: string]: string | undefined;`);
properties.push(
`\t\t[key: \`${env.prefix}\${string}\`]: ${id === 'public' ? 'string | undefined' : 'never'}`
Copy link
Member

Choose a reason for hiding this comment

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

instead of pushing never, shouldn't we just leave out this key/value pair?

Copy link
Member Author

Choose a reason for hiding this comment

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

Agree with not using never, but we should still include this because if we leave this out, the interface will still have the [key: string]: string | undefined signature added below. In that case, accessing variables starting with env.publicPrefix from the /dynamic/private module will return the string | undefined union, which is not as nice compared to only (currently never, changing to) undefined as this will get caught on compile/lint.

@ignatiusmb
Copy link
Member Author

It's not wrong per se, but not narrow enough in that the public dynamic types allow all variables by using [key: string]. We can generate a stricter interface where only keys that starts with the prefix will exists, e.g., [key: `PUBLIC_${string}`] and will error out on typos, or other variables that does not start with PUBLIC_, or even when the user changes their env.publicPrefix option.

Comment on lines 74 to 82
properties.push(
`\t\t[key: \`${env.prefix}\${string}\`]: ${
id === 'public' ? 'string | undefined' : 'undefined'
};`
);

if (id === 'private') {
properties.push(`\t\t[key: string]: string | undefined;`);
}
Copy link
Member

Choose a reason for hiding this comment

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

I think it might make more sense to combine this into

if (id === 'private') {
  // push [key: string] signature
} else {
  // push [`PUBLICPREFIX_${string}`: string] signature
}

(whats the minimum required TS version for this btw? I think it's in our range, right?)

Copy link
Member Author

Choose a reason for hiding this comment

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

I can see that, but it'll look more like this

if (id === 'private') {
  // push { [`PUBLICPREFIX_${string}`: string]: undefined } signature
  // push { [key: string]: string | undefined } signature
} else {
  // push { [`PUBLICPREFIX_${string}`: string]: string | undefined } signature
}

I believe it is within our range, minimum version for this was 4.4 where template literal in index signature was added

Copy link
Member

Choose a reason for hiding this comment

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

Mhm for some reason I thought that private dynamic also includes the public variables for convenience - nevermind then.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants