react-native-dotenv: Importing variables throws an error in TypeScript.
- Asked question in discussions
- Tried the troubleshooting Wiki
- Followed the migration Wiki
Describe the bug Whenever an environment variable is imported from the module, TypeScript throws the following error:
To Reproduce Steps to reproduce the behavior:
- Create an environment variable in
.envfile. - Import the same variable from the module
react-native-dotenvin TypeScript file.
Expected behavior TypeScript should not throw any errors/warnings if the variable exists.
Screenshots My Babel Config is as follows:
Env file:
Version Details React Native Dotenv: ^3.3.1 React Native: 0.66.4 TypeScript: ^4.4.4 React: 17.0.2
Additional context The variables seem to hold values when used in development builds. However, TypeScript should not throw any errors if user has followed all the steps in the documentation.
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 24 (10 by maintainers)
Commits related to this issue
- Update readme instructions for TypeScript As discussed in #269, the "easy instructions" recommended in the Readme do not work. This commit removes the easy instructions. — committed to stevehanson/react-native-dotenv by stevehanson 2 years ago
- Update readme instructions for TypeScript (#360) As discussed in #269, the "easy instructions" recommended in the Readme do not work. This commit removes the easy instructions. — committed to goatandsheep/react-native-dotenv by stevehanson 2 years ago
I feel like the definitely typed package is probably a time waster and shouldn’t be recommended. I tried to think about how it could be fixed but you kinda just need to declare the module types yourself in the end
Ok. My workaround was to create a file named
env.d.tsYep. “@types/react-native-dotenv”: “^0.2.0”,
Ok, last try.
The README is recommending two ways to get typescript to work with this package. OPTION 2 is just to
declareyour env variables by hand. OPTION 1, presented as the easy way, require to install the definitely typed type package.However, as explained by the thread starter, and multiple participants in this thread, this way doesn’t work.
Actually, you agree yourself that it doesn’t work since you wrote
I feel like the definitely typed package is probably a time waster and shouldn't be recommended. I tried to think about how it could be fixed but you kinda just need to declare the module types yourself in the endSo you agree that OPTION1 is not working and shouldn’t be recommended
Hence, the README is wrong.
Thank you.
Sorry that’s my bad for not reading properly, but the way this works is that if something goes wrong, you can suggest that maybe the method doesn’t work at all or you can ask what you did wrong. This is a community where we have to keep our minds open to the possibility that we made a mistake somewhere and that it’s ok because we can learn together. I’m happy to take a look at your code to see why things are not working. Maybe it’s an edge case on the library? Maybe I can update the readme to account to your edge case. I can’t just remove suggestions because you’ve stated it didn’t work for you.
Yup the default import is purposely disabled because the values are replaced by babel in compile
Yes, this is what I’ve been using in my project.