I run a script on a serverless hook using any of the plugins that allow me to do this:
https://www.npmjs.com/package/serverless-scriptable-plugin
https://www.npmjs.com/package/serverless-hooks-plugin
https://www.npmjs.com/package/serverless-plugin-scripts
e.g.
custom:
scriptable:
hooks:
before:deploy:deploy: node createEnvFileInteractive.js
How can I pass in the stage and region variables to the script?
I would say there is 2 option how to do it (at least what I tried and aware of).
pass stage and region as the environment variable:
# serverless.yml
custom:
scriptable:
hooks:
before:deploy:deploy: STAGE=${self:provider.stage} node createEnvFileInteractive.js
Set a js script as a hook and take benefit of serverless object - please check 4th example:
# serverless.yml
custom:
scriptable:
hooks:
before:deploy:deploy: createEnvFileInteractive.js
// createEnvFileInteractive.js
const stage = serverless.service.provider.stage
const region = serverless.service.provider.region
const customValue = serverless.service.custom.customValue
...
//or
const {stage, region} = serverless.service.provider
Related
I'm trying to set up Sveltekit, Supabase and Vercel.
It works correctly on a local environment (SvelteKit and Supabase), but when I deploy it to Vercel there is a problem with Supabase - "Error: supabaseUrl is required" (I post a screenshot below).
If I don't use Supabase, there are no problems with deploying to Vercel.
Please someone if you have encountered a similar one or have a suggestion to share.
I finally got this to work after doing a couple of things I pieced together from a few sources.
First, I added the the environment variables in Vercel just as the were in the .env file. For example, VITE_SUPABASE_URL and VITE_SUPABASE_ANON_KEY along with their values.
Next, I added some code in the svelte.config.js file. The result of the file looks like this:
import adapter from '#sveltejs/adapter-auto'
/** #type {import('#sveltejs/kit').Config} */
const config = {
kit: {
adapter: adapter(),
vite: {
define: {
'process.env': process.env,
},
},
// hydrate the <div id="svelte"> element in src/app.html
target: '#svelte',
},
}
export default config
I redeployed the project at Vercel, and it worked.
You should add your Supabase URL and Supabase ANON KEY to vercel and stick to the format given below VITE_SUPABASE_URL,VITE_SUPABASE_ANON_KEY if you have initialized according to the supabase guide.
More than adding the configuration to your svelte.config.js file, you should emphasize on adding environment variables to your Vercel environment if you have added this file
// utils/supabase.js
import { createClient } from '#supabase/supabase-js'
const supabaseUrl = import.meta.env.VITE_SUPABASE_URL
const supabaseAnonKey = import.meta.env.VITE_SUPABASE_ANON_KEY
export const supabase = createClient(supabaseUrl, supabaseAnonKey)
So I'm happy with the concept of environment variables as explained in this article and others
https://www.freecodecamp.org/news/how-to-gracefully-use-environment-variables-in-a-react-native-app/
Great, I've got my SOMETHING="something" stored so I can just use env.SOMETHING or whatever
The part I'm a little lost on is where you keep the live variables?
I would rather not do a solution like this as it seems you are still keeping your keys quite public and that you are just choosing based on the environment with if statements
Manage environment with expo react native
For example with an Express App deployment we have, we specify
let endPointURL = env.endPointURL
and then we keep a versoin of that variable locally and when it sits with AWS it is overridden by AWS servers as explained here
I was just wondering does something like that exist for Android and iOS builds (on the respective stores) or through Expo?
Thanks all
Honestly I think the way they go about it is a little silly. There may be a better way to go about than this, but I think I followed their documentation suggestions.
https://docs.expo.io/versions/latest/distribution/release-channels/#using-release-channels-for-environment-variable-configuration
They have a code snippet suggesting you create a function to look at the release configuration itself.
I interpreted it that you might do something like the code below and store your environment variables in a variables.js file and pull in your environment variables as such.
import Constants from 'expo-constants';
export const prodUrl = "https://someapp.herokuapp.com";
const ENV = {
dev: {
apiUrl: "http://localhost:3000"
},
staging: {
apiUrl: prodUrl
},
prod: {
apiUrl: prodUrl
}
};
function getEnvVars(env = "") {
if (env === null || env === undefined || env === "") return ENV.dev;
if (env.indexOf("dev") !== -1) return ENV.dev;
if (env.indexOf("staging") !== -1) return ENV.staging;
if (env.indexOf("prod") !== -1) return ENV.prod;
}
export default getEnvVars(Constants.manifest.releaseChannel);
Edit:
Now that Expo supports config file as app.config.js or app.config.ts, we can use the dotenv. Check this: https://docs.expo.io/guides/environment-variables/#using-a-dotenv-file
A simpler approach would be to export the env object instead of the function:
import Constants from 'expo-constants';
import { Platform } from "react-native";
const localhost =
Platform.OS === "ios" ? "localhost:8080" : "10.0.2.2:8080";
const ENV = {
dev: {
apiUrl: localhost,
amplitudeApiKey: null,
},
staging: {
apiUrl: "[your.staging.api.here]",
amplitudeApiKey: "[Enter your key here]",
// Add other keys you want here
},
prod: {
apiUrl: "[your.production.api.here]",
amplitudeApiKey: "[Enter your key here]",
// Add other keys you want here
}
};
const getEnvVars = (env = Constants.manifest.releaseChannel) => {
if (env === null || env === undefined || env === "" || env.indexOf("dev") !== -1) return ENV.dev;
if (env.indexOf("staging") !== -1) return ENV.staging;
if (env.indexOf("prod") !== -1) return ENV.prod;
}
const selectedENV = getEnvVars();
export default selectedENV;
// Import
import env from '..xxx/utility/env';
Get it in your ios-generated file, based on .env file:
In .env, write down GOOGLE_MAPS_API=abcde...
yarn add react-native-config
cd ios
pod install
In your Objective-C-compiled code, for example, AppDelegate.m:
#import "ReactNativeConfig.h"
NSString *mapsApiKey = [ReactNativeConfig envFor:#"GOOGLE_MAPS_API"];
[GMSServices provideAPIKey:mapsApiKey];
Credits to: ReactNative: Pass JS variable to AppDelegate based on https://github.com/luggit/react-native-config.
Android should work as well, but haven't tested / followed https://github.com/luggit/react-native-config.
Edit: required steps for Android:
<meta-data android:name="com.google.android.geo.API_KEY" android:value="#string/GOOGLE_MAPS_API"/> in AndroidManifest.xml.
In settings.gradle:
include ':react-native-config'
project(':react-native-config').projectDir = new File(rootProject.projectDir, '../node_modules/react-native-config/android')
right after rootProject.name = 'XYZ'
In build.gradle:
apply from: project(':react-native-config').projectDir.getPath() + "/dotenv.gradle" right below import com.android.build.OutputFile and implementation project(':react-native-config') right below implementation "com.facebook.react:react-native:+" // From node_modules
Regarding "normal" usage in .ts, .tsx, .js files I'm declaring variables in .env based on https://github.com/goatandsheep/react-native-dotenv by declaring "module:react-native-dotenv" in babel.config.js in plugins, and it works like a charm like so:
import { ACCESS_TOKEN } from "#env";
...
headers: {
Authorization: `Bearer ${ACCESS_TOKEN}`,
Accept: "application/json",
},
Edit: important the eas build ignores .gitignore-declared variable, so if your .env is in .gitignore the production bundle won't have it included.
Surprised there weren't any answers that involved storing environment variables in a .env file with Expo.
I prefer storing my environment variables in a .env file because I don't want to commit certain variables to version control and hardwire them into my application code.
Create your .env file and add your environment variables
Install dotenv
npm install dotenv
In your app.config.js file, load the environment variables from the .env file via dotenv:
require("dotenv").config();
export default {
// config...
}
Expose the environment variables to the Expo runtime in the config in app.config.js:
require("dotenv").config();
export default {
// rest of config...
extra: {
ENV_VAR: process.env.ENV_VAR
}
}
Now you can access your environment variables through the following:
import Constants from "expo-constants";
const ENV_VAR = Constants.expoConfig.extra.ENV_VAR
OPTIONAL: TypeScript
To make using environment variables in our code a little nicer, lets create a typed helper utility to access the environment variables:
import Constants from "expo-constants";
export interface Env {
ENV_VAR: string;
}
/**
* Environment variables exposed through `app.config.js`
* An environment variable not there? Make sure it is explicitly defined in `app.config.js`
*/
export const env = Constants.expoConfig?.extra as Env;
Then you can simply access your environment variables from the env object:
const ENV_VAR = env.ENV_VAR
OPTIONAL: Throw an error if an environment variable is not set
This can be handy to prevent your app from running if an environment variable required for your app to properly function is not set.
In your app.config.js:
// Validate all necessary environment variables are set
const checkForEnvVariable = (envVar) => {
if (!process.env[envVar]) {
throw Error(`${envVar} not set! Check env.md for more information`);
}
};
[
"ENV_VAR",
// ...
].forEach((envVar) => checkForEnvVariable(envVar));
I get the following warning after building my project with vue cli 3:
After some look up I found out that there is no need to create a webpack.config.js as it is written here (or here):
The initial project doesn't require the file to exist because you just created a project with fresh "default" settings that don't require any config.
The Vue CLI documentation offers a vue.config.js which is optional and will be automatically loaded if it's present in the project root. Also it seems possible to work with webpack in the vue.config.js like this.
I'm totally new to webpack and couldn't figure out how to limit the size of my entrypoints with the code splitting that is provided in the message of the warning abouve. Can somebody please give me a hint how to solve this using the vue.config.js file?
We can also split each route's component into separate chunks and only load them when the route is visited.
In your router.js file:
// replace
// import UserDetails from './views/UserDetails'
// with
const UserDetails = () => import('./views/UserDetails')
const router = createRouter({
// ...
routes: [{ path: '/users/:id', component: UserDetails }],
})
For further information read the official documentation.
Try to load your components asynchronously.
Also prefer local component registration over global.
I was wondering whats the best way to do something like nuxtClientInit. I'm trying to load the Auth State as early as possible on the client and save it in my vuex store but not on the server side. It would be great if vuex had something like the created hook for components but that doesn't exist to my knowledge.
How could I achieve this behavior? One way could be calling an action from a layout but is that the best way?
I understand the nuxt team are working on a nuxtClientInit feature but before they release that you could just make your own. To understand the workflow that nuxt undertakes when there is a request you can look at the lifecycle here. This shows that nuxtServerInit is called first then middleware. During this middleware call nuxt.config.js is served and this contains your custom configuration. Part of this is 'plugins' which as the docs say,
This option lets you define JavaScript plugins that should be run
before instantiating the root Vue.js application.
So if you write a plugin to call a store action you can then get and set your local storage from there. So, start with a nuxt-client-init plugin:
//nuxt-client-init.client.js
export default async context => {
await context.store.dispatch('nuxtClientInit', context)
}
then add the plugin to nuxt.config.js:
//nuxt.config.js
plugins: [
'~/plugins/nuxt-client-init.client.js'
],
If you notice the naming convention here, the .client.js part of the plugin tells nuxt this is a client only plugin and is shorthand for '{ src: '~/plugins/nuxt-client-init.js', mode: 'client' }' which since nuxt 2.4 is the way to define the old '{ src: '~/plugins/nuxt-client-init.js', ssr: false }'. Anyway, you now have a call to your store so you can have an action to call from local storage and set a state item.
//store/index.js
export const actions = {
nuxtClientInit({ commit }, { req }) {
const autho = localStorage.getItem('auth._token.local') //or whatever yours is called
commit('SET_AUTHO', autho)
console.log('From nuxtClientInit - '+autho)
}
}
You probably need to restart your app for that to all take effect but you are then getting and using your Auth State without any of that pesky nuxtServerInit business.
I am using WebdriverIO for test automation. In wdio.conf.js file I have configured the 'baseUrl' property.
I want to read the 'baseUrl' property value inside my test .js file. How can I do this?
❒ wdio-v5
Lately, after writing a lot of tests for a project rewrite I've came to believe the best way to store/access global config variables is via the global object.
You can define them inside the wdio.conf.js file's hooks. I defined mine in the before hook:
before: function (capabilities, specs) {
// =================
// Assertion Library
// =================
const chai = require('chai');
global.expect = chai.expect;
global.assert = chai.assert;
global.should = chai.should();
// ======================
// Miscellaneous Packages
// ======================
global.langCode = langCode;
global.countryCode = countryCode;
global.request = require('superagent');
global.allowedStatusCodes = [200, 301],
// ===============
// Custom Commands
// ===============
require('./test/custom_commands/aFancyMethod');
require('./test/custom_commands/anotherOne');
require('./test/custom_commands/andAnotherOne');
},
Then, you can access them directly, anywhere in your test-files, or page-objects. This way, you greatly reduce the test-file's footprint (errr... codeprint) because you can call these directly in your test case:
describe(`Testing a random URL`, () => {
it('Should return a HTTP valid status code', async () => {
// Issue a HTTP request for the given URL:
await request
.head('https://random.org')
.then(res => {
console.info(`\n> Status code found: ${res.status} | MIME type found: '${res.type}'\n`);
foundStatusCode = res.status;
})
.catch(err => {
console.info(`\n> Status code found: ${err.status} | Error response found: '${JSON.stringify(err.response)}'\n`);
foundStatusCode = err.status;
});
// Assert the HTTP Status Code:
assert.include(allowedStatusCodes, foundStatusCode, `!AssertError: Route yields a bad status code! Got: ${foundStatusCode} | Expected: ${allowedStatusCodes}`);
});
As opposed to always doing await browser.options.request.head(..., browser.options.baseUrl, etc.
❒ wdio-v4
All the wdio.conf.js file attributes (basically the config object name-value pairs) are also stored inside the browser.options object.
Thus, a more elegant approach to access your global config values from inside your tests would be as presented below:
> browser.options
{ port: 4444,
protocol: 'http',
waitforTimeout: 10000,
waitforInterval: 500,
coloredLogs: true,
deprecationWarnings: false,
logLevel: 'verbose',
baseUrl: 'http://localhost',
// ... etc ...
}
> browser.options.baseUrl
'http://localhost'
I'll go on a limb here and presume you want to read the baseUrl value from your wdio.config.js file, into your test.js file.
TL;DR: In your test.js file heading, add the following:
var config = require('<pathToWdioConfJS>/wdio.conf.js').config;
You can then access any wdio.config.js value via the config.<configOption>, in your case config.baseUrl.
Lastly, I would greatly recommend you read about exports and module exports.
WebdriverIO is built on NodeJS, so you will shoot yourself in the foot on the long run if you don't know how and when to use exports, module.exports, require, or the difference between them.
Use browser.options.baseUrl . If you use require, you're hard coding from that one file, which is fine, but you cannot do a wdio --baseUrl=http://myTestSite2.net to override the "global" baseUrl. Which you might want to do in multiple deployments in the future.
In wdio.config.js file define the url like this
var baseUrl = 'YOUR URL'
exports.config = {
baseUrl: baseUrl,
}
In Test file use / instead of adding complete url in browser.url('/'), it will use the baseUrl from the wdio.config.js file.
browser.url('/')
BaseUrl is available in the config object browser.config.baseUrl
See https://github.com/webdriverio/webdriverio/blob/a4a5a46f786f8548361d7f86834b38f89dcb1690/packages/webdriverio/webdriverio-core.d.ts#L131
just save all your variable in before: function and can be used anywhere in your test.
like the following example i use retry count wdio config file
before: function (capabilities, specs) {
expect = require('chai').expect;
should = require('chai').should();
assert = require('assert');
retryCount=2;
browser.maximizeWindow();