I'm running Rails v5 with Webpacker v2. Everything's been smooth so far, but I've hit one hiccup: how to expose Rails helpers to my TypeScript.
I know Webpacker ships with rails-erb-loader, so I was expecting that I'd be able to add .erb to a TypeScript file, and then import that file elsewhere:
// app/javascript/utils/rails.ts.erb
export const env = "<%= Rails.env %>"
export function isEnv(envName: string) {
return env == envName
}
// app/javascript/packs/application.ts
import { env } from "../utils/rails"
But Webpack can't find the "rails" file even if I modify the typescript loader to include ERB files:
module.exports = {
test: /.ts(\.erb)?$/,
loader: 'ts-loader'
}
All I see is:
error TS2307: Cannot find module '../utils/rails'.
What's the best way to go about exposing Rails helpers and variables to my JavaScript?
Rails env comes from your environment variable. This means you configure it by setting (in bash for example) the variable in this way:
export RAILS_ENV=production
As a consequence, you don't need to deal with Rails at all.
// app/javascript/utils/rails.ts.erb
export const env = process.env.RAILS_ENV || "development"
export function isEnv(envName: string) {
return env == envName
}
This comes with a great advantage: you don't have to load the whole rails app just to compile your javascript. Rails can become really slow on first load if your app grows.
Since you won't have access to process.env on the frontend (browser), you also need a way to make it exist. In webpack, this is done through the DefinePlugin:
Update your webpack configuration to use the plugin (in plugins section): new webpack.DefinePlugin({ "process.env": { RAILS_ENV: process.env.RAILS_ENV } }) and you will get a process.env.RAILS_ENV available in the client
Rails Env can be accessed through:
process.env.RAILS_ENV
Related
I read about serverRuntimeConfig here: https://nextjs.org/docs/api-reference/next.config.js/runtime-configuration
Now my next.config.js is:
module.exports = withCSS({
target: 'serverless',
reactStrictMode: false,
env: {
SECRET: 'SECRET'
}
});
I'm wondering, should I use serverRuntimeConfig for my secret env var instead of env ?
What are the pros / cons ?
Generally you'll want to use build-time environment variables to provide your configuration. The reason for this is that runtime configuration adds rendering / initialization overhead and is incompatible with Automatic Static Optimization.
# https://nextjs.org/docs/api-reference/next.config.js/runtime-configuration
As they said, the runtime configuration in next.config.js may cause overhead.
So I suggest using env in next.config.js, or using the .env* files in this new method (https://nextjs.org/docs/basic-features/environment-variables)
The code using your secret env vars should be in the server-side (API routes, getStaticProps, getServerSideProps), not in client-side (components...). If you reference them in client-side, they may be exposed!
Is it possible to access my Rails environment variables from webpacker bundles? I know I can use dotenv, but the project uses Figaro and I would prefer not to change that. I would really like to pass the env vars from Rails to webpacker during compilation of the bundles.
I just ran into the same problem. If you put your .env file in config/webpack and then add this code to your config/webpack/application.js file, you should be good:
const dotenv = require('dotenv')
dotenv.config({path: __dirname + '/.env'})
environment.plugins.insert(
"Environment",
new webpack.EnvironmentPlugin(process.env)
)
I'm using webpacker 5.4.3 and I use dotenv-webpack to solve this problem.
yarn add -D dotenv-webpack
Put the ".env*" files in your Rails project root directory, then edit environment.js:
// config/webpack/environment.js
const { environment } = require('#rails/webpacker')
const Dotenv = require('dotenv-webpack');
environment.plugins.prepend('Dotenv', new Dotenv());
// your other settings...
module.exports = environment
Then you can access the environments through process.env
# .env
ABC=123
//packs/application.js
console.log(process.env.ABC)
// => 123
When building a Gatsby project I'm getting all env variables undefined in production environment.
In development everything is fine.
I have 2 similar .env.development and .env.production files.
In my gatsby-config.js I have
require('dotenv').config({
path: `.env.${process.env.NODE_ENV}`,
});
and if I console.log(process.env.NODE_ENV) during gatsby build it gives production and the variables can be accessed and logged out.
But later in code something like
return request.post(`${process.env.GEOCODING_CF_URL}/latlng`, {...});
gives request to http://localhost:9000/ru/undefined/latlng.
What am I doing wrong and how this issue can be fixed?
UPDATE:
When I run gatsby build - process.env.NODE_ENV is production
When I run gatsby serve - process.env.NODE_ENV is undefined
If this can help in any way.
If you use environment variables in node you don't need a prefix (like in your gatsby-config.js). However, if you need to use them in a component or a page you must add GATSBY_ as a prefix, so GEOCODING_CF_URL should be GATSBY_GEOCODING_CF_URL
For me, NODE_ENV=production yarn gatsby serve did the trick.
https://www.gatsbyjs.com/docs/how-to/local-development/environment-variables/
Accessing Environment Variables in the browser.
By default, environment variables are only available in Node.js code and are not available in the browser as some variables should be kept secret and not exposed to anyone visiting the site.
To expose a variable in the browser, you must preface its name with GATSBY_. So GATSBY_API_URL will be available in browser code but API_KEY will not.
Variables are set when JavaScript is compiled so when the development server is started or you build your site.
src/pages/index.js
Copysrc/pages/index.js: copy code to clipboard
import React, { useState, useEffect } from "react"
function App() {
const [data, setData] = useState()
useEffect(async () => {
const result = await fetch(
`${process.env.GATSBY_API_URL}/users`
).then(res => res.json())
setData(result.data)
})
return (
<ul>
{data.map(user => (
<li key={user.id}>
<a href={user.url}>{user.name}</a>
</li>
))}
</ul>
)
}
export default App
I'm trying to add TypeScript to an existing VueJS + Rails app. I cloned this demo (https://github.com/gbarillot/rails-vue-demo-app) then followed the instructions from https://github.com/rails/webpacker
$ bundle exec rails webpacker:install:vue
$ bundle exec rails webpacker:install:typescript
I then modified config/webpack/loaders/typescript.js as described here.
Everything seems to compile, but when I go into my "home" view and change the script to typescript:
<script lang="ts">
import Layout from '../shared/layout';
export default {
components: {
Layout
}
}
</script>
I get the following error:
Failed to compile.
/Users/matt/projects/rails-vue-demo-app/app/javascript/packs/components/home/index.vue.ts
[tsl] ERROR in /Users/matt/projects/rails-vue-demo-app/app/javascript/packs/components/home/index.vue.ts(13,20)
TS2307: Cannot find module '../shared/layout'.
Why can I no longer find the layout file when typescript is enabled?
I remember running into a similar problem for presentational components. Try adding an empty export in shared/layout so typescript can pick it up:
<script lang="ts">
export default {}
</script>
How do I make packaged releases of my Electron application set NODE_ENV=production when packaged with electron-packager?
UPDATE 2019/12
Use app.isPackaged: https://electronjs.org/docs/api/app#appispackaged-readonly
It returns true if the app is packaged, false otherwise. Assuming you only need a check if it's in production or not, that should do it. The env file solution detailed below would be more suitable if you had different environments/builds with different behaviors.
To my knowledge, you can't pass env vars to a packaged electron app on start (unless you want your users to always start it from the command line and pass it themselves). You can always set that env variable in your application like this: process.env.NODE_ENV = 'production'. You could integrate that with electron-packager by having an env file that gets set in your build and is required by your application to determine what environment it's in.
For example, have a packaging script that looks like:
"package": "cp env-prod.json src/env.json && npm run build"
and in your src/main.js file:
const appEnv = require('./env.json');
console.log(appEnv) //=> { env: "prod", stuff: "hey" }
//you don't really need this, but just in case you're really tied to that NODE_ENV var
if(appEnv.env === 'prod') {
process.env.NODE_ENV = 'production';
}
You can set it in 2 ways.
By command line with --no-prune see here in the usage guide
Or programmatically with this API
var packager = require('electron-packager');
var options = {
'arch': 'ia32',
'platform': 'win32',
'dir': './'
'prune': true //this set the enviroment on production and ignore dev modules
};
packager(options, function done_callback (err, appPaths) { /* … */ })
For more options see this guide