
ການໃຊ້ງານ .env (Environment Variables) ໃນ ViteJS
/ 2 min read
Updated:Table of Contents
ການໃຊ້ງານ .env ໃນ ViteJS
ມື້ນີ້ຊິມາແນະນຳການໃຊ້ງານ file .env ໃນໂປຼເຈັກ ViteJS.
ຖ້າວ່າເຮົາມີການໃຊ້ external APIs ເພື່ອເຊື່ອມຕໍ່ກັບແອັບພິເຄຊັນ ເຊັ່ນໃຊ້ Firebase ເຮົາກໍຄວນທີ່ຈະເກັບ API Key ເຊິ່ງເປັນຂໍ້ມູນທີ່ສຳຄັນໄວ້ໃນ .env. ການຈັດເກັບແບບນີ້ຊ່ວຍໃຫ້ເຮົາເອີ້ນໃຊ້ Key ທີ່ຕ້ອງການໄດ້ທຸກ file ຂອງໂປຼເຈັກ ເມື່ອຕ້ອງການປ່ຽນແປງຂໍ້ມູນກໍງ່າຍ ບໍ່ຈຳເປັນຕ້ອງໄປໄລ່ປ່ຽນທຸກບ່ອນ ແປງຢູ່ .env ບາດດຽວຈົບ.
ສ້າງ file .env
ໃຫ້ສ້າງ file ຊື່ .env ໄວ້ທີ່ root ຂອງໂປຼເຈັກ (ບ່ອນດຽວກັນກັບ package.json ແລະ vite.config.js) ບໍ່ແມ່ນໄວ້ໃນ folder src.
ກົດສຳຄັນ: ຕ້ອງຂຶ້ນຕົ້ນດ້ວຍ VITE_
ນີ້ຄືຈຸດທີ່ຫຼາຍຄົນຕິດ. Vite ຈະ ບໍ່ເປີດເຜີຍ ຕົວແປໃຫ້ code ຝັ່ງ client ນຳໃຊ້ໄດ້ ນອກຈາກວ່າຕົວແປນັ້ນຈະຂຶ້ນຕົ້ນດ້ວຍ VITE_. ນີ້ເປັນເລື່ອງຄວາມປອດໄພ ເພື່ອປ້ອງກັນບໍ່ໃຫ້ເຮົາ “ເຜີ” secret ທີ່ບໍ່ຄວນອອກໄປໂດຍບັງເອີນ.
ສະນັ້ນພາຍໃນ .env ໃຫ້ຕັ້ງຊື່ແບບນີ້:
VITE_API_URL=https://api.example.comVITE_APP_TITLE=ແອັບຂອງຂ້ອຍຖ້າຕັ້ງ API_URL=... ໂດຍບໍ່ມີ VITE_ ນຳໜ້າ ເຮົາຈະເອີ້ນໃຊ້ໃນ code ບໍ່ໄດ້ (ມັນຈະອອກມາເປັນ undefined).
ເອີ້ນໃຊ້ດ້ວຍ import.meta.env
ຕ່າງຈາກ Create React App ທີ່ໃຊ້ process.env, Vite ໃຊ້ import.meta.env ແທນ:
console.log(import.meta.env.VITE_API_URL);// "https://api.example.com"
const title = import.meta.env.VITE_APP_TITLE;ນອກນັ້ນ Vite ຍັງມີຕົວແປ built-in ມາໃຫ້ນຳ ເຊັ່ນ import.meta.env.MODE (development ຫຼື production), import.meta.env.PROD ແລະ import.meta.env.DEV ທີ່ໃຫ້ຄ່າ boolean ມີປະໂຫຍດເວລາຢາກໃຫ້ code ເຮັດວຽກຕ່າງກັນລະຫວ່າງຕອນ dev ກັບຕອນ build ຂຶ້ນ production.
ຕົວຢ່າງຈິງ: ຕັ້ງຄ່າ Firebase
ສົມມຸດເຮົາໃຊ້ Firebase, ໃຫ້ເອົາຄ່າ config ທັງໝົດໄປໄວ້ໃນ .env:
VITE_FIREBASE_API_KEY=AIzaSyXXXXXXXXXXXXXXXXXXXXVITE_FIREBASE_AUTH_DOMAIN=my-app.firebaseapp.comVITE_FIREBASE_PROJECT_ID=my-appVITE_FIREBASE_APP_ID=1:1234567890:web:abcdefແລ້ວເອີ້ນໃຊ້ຢູ່ file ຕັ້ງຄ່າ Firebase:
import { initializeApp } from "firebase/app";
const firebaseConfig = { apiKey: import.meta.env.VITE_FIREBASE_API_KEY, authDomain: import.meta.env.VITE_FIREBASE_AUTH_DOMAIN, projectId: import.meta.env.VITE_FIREBASE_PROJECT_ID, appId: import.meta.env.VITE_FIREBASE_APP_ID,};
export const app = initializeApp(firebaseConfig);ແບບນີ້ເວລາຍ້າຍໂປຼເຈັກໄປ environment ໃໝ່ (ເຊັ່ນຈາກ dev ໄປ production) ກໍພຽງແຕ່ປ່ຽນຄ່າໃນ .env ໂດຍບໍ່ຕ້ອງໄປແກ້ code.
ຢ່າລືມ .gitignore
ສິ່ງສຳຄັນທີ່ບໍ່ຄວນລືມ: ໃຫ້ເພີ່ມ .env (ໂດຍສະເພາະ .env.local) ໄວ້ໃນ .gitignore ເພື່ອບໍ່ໃຫ້ຂໍ້ມູນທີ່ sensitive ຫຼຸດຂຶ້ນໄປຢູ່ Git repo ສາທາລະນະ:
.env.local.env.*.localໝາຍເຫດ: ຄ່າ config ຂອງ Firebase ຝັ່ງ web ນັ້ນຕາມຈິງແລ້ວເປັນຄ່າ public (ມັນຕ້ອງຖືກສົ່ງໄປ browser ຢູ່ແລ້ວ) ການຄວບຄຸມສິດທິແທ້ໆແມ່ນຢູ່ທີ່ Firebase Security Rules ບໍ່ແມ່ນຢູ່ການເຊື່ອງ API Key. ແຕ່ການເກັບໄວ້ໃນ
.envກໍຍັງດີ ເພາະເຮັດໃຫ້ສະອາດ ແລະ ປ່ຽນ environment ໄດ້ງ່າຍ.
file .env ຫຼາຍແບບ
Vite ຮອງຮັບ .env ຫຼາຍ file ຕາມ mode:
| file | ໂຫຼດເມື່ອໃດ |
|---|---|
.env | ໂຫຼດທຸກກໍລະນີ |
.env.local | ໂຫຼດທຸກກໍລະນີ ແຕ່ຖືກ ignore ໂດຍ git |
.env.development | ໂຫຼດສະເພາະຕອນ vite (dev) |
.env.production | ໂຫຼດສະເພາະຕອນ vite build (production) |
ປະໂຫຍດຄື: ເຮົາສາມາດໃຊ້ API ຄົນລະ endpoint ລະຫວ່າງ dev ກັບ production ໄດ້ໂດຍບໍ່ຕ້ອງແກ້ code ເລີຍ.
ສ່ວນຕົວ ມື້ກ່ອນຂ້ອຍເຄີຍ hard-code API Key ໄວ້ໃນ code ກົງໆ ແລ້ວເຜີ່ຫຼຸດຂຶ້ນ GitHub ຈົນຖືກເຕືອນ ພໍຮູ້ຈັກ .env ແລ້ວຊີວິດປ່ຽນໄປເລີຍ. ມັນບໍ່ໄດ້ຍາກຫຍັງ ແຕ່ຊ່ວຍໃຫ້ໂປຼເຈັກເປັນລະບຽບຂຶ້ນຫຼາຍ. ໃຜທີ່ກຳລັງເລີ່ມຫັດໃຊ້ Vite ລອງເອົາໄປໃຊ້ເບິ່ງເດີ້. ອ່ານເພີ່ມເຕີມໄດ້ທີ່ ເອກະສານທາງການຂອງ Vite ເລື່ອງ Env Variables.


