Skip to content
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.

Sign up for GitHub

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

Jump to bottom

feat: env vars should be readonly #111

Merged
merged 8 commits into from
Aug 17, 2023
Merged

feat: env vars should be readonly #111

merged 8 commits into from
Aug 17, 2023

Conversation

Zamiell
Copy link
Contributor

@Zamiell Zamiell commented Aug 16, 2023

Closes #108

@vercel
Copy link

vercel bot commented Aug 16, 2023 •
edited
Loading

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
t3-env ✅ Ready (Inspect) Visit Preview 💬 Add feedback Aug 17, 2023 8:49pm

@vercel
Copy link

vercel bot commented Aug 16, 2023

@Zamiell is attempting to deploy a commit to the t3-oss Team on Vercel.

A member of the Team first needs to authorize it.

Zamiell
Zamiell commented Aug 16, 2023
View reviewed changes
juliusmarminge
juliusmarminge approved these changes Aug 17, 2023
View reviewed changes
Copy link
Member

@juliusmarminge juliusmarminge left a comment •
edited
Loading

Choose a reason for hiding this comment

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

Add a test like this too for good measure and to show what we're after:

// @ts-expect-error - readonly
env.FOO = true

Should we also Object.freeze something?

Zamiell
Zamiell commented Aug 17, 2023
View reviewed changes
@Zamiell
Copy link
Contributor Author

Zamiell commented Aug 17, 2023 •
edited
Loading

Should we also Object.freeze something?

Personally I'm not a fan of Object.freeze (or the set hack that you added to the PR).

Pros

  • Ensures that the readonly state persists into the runtime, making the object even safer.

Cons

  • Object.freeze is superfluous in TypeScript-only applications. And we don't ever expect that someone would be exporting their application's environment variables to some kind of JavaScript-only consumer, so the runtime safety is truly pointless.
  • Prevents live runtime debugging using the Chrome development console.
  • Adds complexity to t3-oss.

Overall it seems like the cons outweigh the pros. Also note that there is no performance benefit to doing this.

juliusmarminge
juliusmarminge reviewed Aug 17, 2023
View reviewed changes
@Zamiell
Copy link
Contributor Author

Zamiell commented Aug 17, 2023

im not a fan of committing commented out code into a repository, can I remove this please?

@juliusmarminge juliusmarminge added this pull request to the merge queue Aug 17, 2023
@Zamiell Zamiell disabled auto-merge August 17, 2023 20:44
@juliusmarminge
Copy link
Member

im not a fan of committing commented out code into a repository, can I remove this please?

Nah I want it as a reference to why the behavior is the way it is if we come back to it in the future

@juliusmarminge juliusmarminge removed this pull request from the merge queue due to a manual request Aug 17, 2023
@juliusmarminge juliusmarminge added this pull request to the merge queue Aug 17, 2023
@juliusmarminge juliusmarminge removed this pull request from the merge queue due to a manual request Aug 17, 2023
@juliusmarminge juliusmarminge merged commit 6890765 into t3-oss:main Aug 17, 2023
@juliusmarminge juliusmarminge mentioned this pull request Aug 17, 2023
Merged
@Zamiell Zamiell deleted the readonly branch August 18, 2023 13:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@juliusmarminge juliusmarminge juliusmarminge approved these changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

environment variables should be read-only, but they are not
2 participants
@Zamiell @juliusmarminge