Personnellement, je ne m'inquiéterais pas trop de l'indisponibilité de process.env sur le client. Il faut déjà savoir que 'window' n'est pas disponible sur le serveur ; il est logique pour moi que process.env ait le comportement inverse. (il n'y a pas de processus de nœud pour lequel avoir un env, et les navigateurs n'exposent pas leurs vars d'env que je connaisse) Je pense à process.env comme un endroit où les secrets du serveur peuvent se retrouver, donc je préférerais que ce soit indisponible côté client par défaut.

Si cela ne tenait qu'à moi, les variables process.env.RAZZLE_INLINED_XXXXXX seraient compilées pendant la construction (et disponibles sur le client sous forme de chaînes DefinePlugin'd en ligne) et tout le reste ne serait disponible que côté serveur.

NODE_ENV peut également être intégré, car il est principalement utilisé comme description de la construction et non comme quelque chose de variable comme l'environnement dans lequel le code s'exécute. Il existe également des raisons de performances pour le faire.

J'aime l'idée que PORT et HOST soient variables au moment de l'exécution. J'exécute peut-être les mêmes artefacts de build dans différents environnements.

Je peux confirmer la lutte. Le comportement actuel n'était pas ce à quoi je m'attendais et m'a particulièrement fait trébucher lors du déploiement avec up sur aws. J'ai maintenant personnalisé le razzle.config.js afin que toutes les variables spécifiques à razzle soient préfixées par RAZZLE_XXX et qu'elles soient stringifiées au moment de la compilation. Le reste est disponible sur process.env.XXX . Je suis également d'accord avec @gregmartyn au sujet de l'indisponibilité des variables d'exécution via process.env .

En essayant de configurer Razzle dans un projet React existant, nous avons rencontré ce problème. Le port n'est pas remplaçable au moment de l'exécution et les autres variables process.env ne sont pas disponibles sur le serveur.

Comportement actuel au moment de la construction :

process.env.PORT
process.env.NODE_ENV;
process.env.ASSETS_MANIFEST;
process.env.HOSTING_SET_VARIABLE;

devient à la fois client et serveur :

3000;
'development';
'/Users/[...]/build/assets.json';
undefined;

Bien que cela garantisse que le client et le serveur peuvent utiliser exactement les mêmes environnements de processus, cela rend impossible le remplacement au moment de l'exécution ou l'utilisation d'autres variables d'environnement.

Si vous voulez être entièrement compatible avec les versions antérieures, il doit être transpilé dans celui-ci au moment de la construction (sur le serveur, le client peut rester le même) :

process.env.PORT || 3000;
process.env.NODE_ENV || 'development';
process.env.ASSETS_MANIFEST || '/Users/[...]/build/assets.json';
process.env.HOSTING_SET_VARIABLE;

De cette façon, vous pouvez utiliser process.env.PORT à la fois sur le client et sur le serveur. Il sera par défaut à 3000.

Si razzle est _built_ avec PORT=80 , le client fait transpiler process.env.PORT en 80 et le serveur le fera transpiler en process.env.PORT || 80 . Cela entraînera le même comportement que maintenant.

Si razzle est _run_ avec PORT=81 (bien qu'il soit construit avec 80 ), la variable d'environnement client restera 80 tandis que la variable serveur donnera 81 .

Ce comportement peut bien sûr conduire à un comportement inattendu, mais il offre l'utilisation la plus flexible de process.env tout en maintenant une compatibilité descendante totale. Le port peut toujours être écrasé sur le serveur au moment de l'exécution, et d'autres variables d'environnement définies par les plates-formes d'hébergement fonctionneront sur le serveur en l'état.

Je pense que le problème sous-jacent ici est que Razzle essaie actuellement de regrouper plusieurs fonctions disparates dans un seul objet et de modifier fondamentalement les fonctionnalités existantes.

Il essaie de :

1. Transformez les variables process.env en constantes pour des raisons de performances (voir l'exemple de minification sur https://webpack.js.org/plugins/define-plugin/#usage et la lenteur de nodejs sur https://github.com/nodejs/node/issues /3104)
2. Rendez ces constantes disponibles à la fois pour le serveur et le client afin que le code isométrique ait moins à se soucier.

Problèmes:

• process.env est pour l'environnement _variables_. Le transformer en un ensemble de constantes modifie son comportement attendu.
• process.env contient souvent des informations sensibles, y compris des mots de passe, ce n'est donc pas une excellente source de données à partager avec le client. S'il est partiellement partagé et partiellement non partagé, le développeur doit savoir que cette seule chose -- process.env -- non seulement ne se comporte pas comme elle le fait nativement, mais qu'elle a également un comportement différent en fonction des préfixes des clés.
• Il est transformé en constantes au moment de la construction, ce qui est différent de la façon dont les variables d'environnement se comportent dans d'autres contextes. Docker, par exemple, fait une distinction entre les variables au moment de la construction (utiles lorsque la construction elle-même nécessite des informations variables selon l'endroit où elle s'exécute) et les variables d'environnement (utiles lorsqu'une image prédéfinie est déployée dans différents environnements). Elastic Beanstalk, Heroku et al. faire de même.
• Le préfixe "RAZZLE_RUNTIME_" suggéré n'est pas explicite. Il doit indiquer qu'il est disponible côté client et qu'il ne s'agit pas d'une variable. Je pense que "INLINED_" couvre cela, car l'inline est couramment utilisé pour faire référence à quelque chose qui se produit au moment de la construction. Ce n'est pas parfait ("ISOMORPHIC_INLINED_" ?), mais il essaie aussi d'être court.

Ma préférence serait de diviser cette fonctionnalité en différentes parties et de ne pas altérer du tout process.env.
Le DefinePlugin pourrait appeler un fichier comme razzle.config.js pour obtenir les constantes de construction
Il est recommandé d'utiliser un modèle similaire à ce que Redux fait avec configureStore(window.__PRELOADED_STATE__) pour transmettre les données du serveur au client.

Pour une compatibilité descendante, les notes de mise à niveau peuvent fournir un exemple de razzle.config.js qui définit la méthode à l'ancienne.

Un addendum : j'ai dit "de ne pas altérer du tout process.env". mais je pouvais voir qu'il y avait une exception pour process.env.NODE_ENV pour les raisons de performances de mon commentaire ci-dessus et que "NODE_ENV" lui-même a généralement pris le sens de "NODE_ENV = production signifie qu'il s'agit d'une version optimisée"

@gregmartyn, nous devons définir NODE_ENV pour les optimisations de performances et utiliser le préréglage babel comme cela fonctionne maintenant. Mon raisonnement initial pour jouer avec env était de rendre le passage de CRA beaucoup plus facile car SSR est souvent ajouté après qu'un projet a déjà commencé. Nous utilisons également CRA sur d'autres projets, ce qui simplifie (légèrement) notre outillage de construction.

Oui; convenu que NODE_ENV est une exception utile. C'est son propre truc et étroitement lié à la construction, donc ce n'est pas surprenant. J'ai sauté directement sur CRA à partir d'une solution SSR personnalisée, donc je ne suis pas vraiment familier avec la façon dont ils font les choses. Il semble que ce soit un problème là-bas aussi : https://github.com/facebook/create-react-app/issues/2353

Je pense que c'est un problème plus important pour Razzle que pour CRA, car le code d'exécution d'une application CRA ne s'exécute pas du tout sur le serveur. CRA peut faire ce qu'il veut avec process.env car en ce qui concerne son code côté client, il serait vide sinon. Razzle, d'autre part, démarre express pour son SSR, et ce code s'attendrait raisonnablement à ce que process.env ait sa sémantique habituelle avec un accès à l'ensemble complet des variables d'environnement d'exécution du nœud. Process.env a une signification réelle sur le serveur, il est donc regrettable que CRA l'ait coopté pour un cas d'utilisation différent. Ils auraient pu utiliser un autre nom au lieu de "process.env" comme "cra.inlines". Au lieu de cela, le code isomorphe est touché par une décision qui a été prise en ne considérant que le côté client.

Il convient de noter en rouge partout que les variables d'environnement RAZZLE_XXX sont TOUTES disponibles sur le client.

Comment utiliser des variables d'environnement sensibles sans qu'elles soient envoyées au client ?

Ils ne sont pas envoyés au client sauf si vous les référencez en code isomorphe

@jaredpalmer peut-être que ce problème est spécifique à afterjs alors? Je ne les référence que dans le code serveur.

J'aimerais ajouter un vote pour la possibilité de définir des variables d'environnement sans le préfixe RAZZLE . À tout le moins, process.env ne doit pas être effacé côté serveur, ce qui vous empêche d'utiliser quelque chose comme dotenv pour charger des variables d'environnement côté serveur. Cela semble être une hypothèse beaucoup trop intrusive à faire sur l'environnement d'application.

Je ne sais pas très bien comment razzle injecte actuellement des variables d'environnement dans le client et le serveur, mais vous ne voudriez certainement pas de trucs spécifiques au serveur sur le client. Malheureusement, c'est une sorte de rupture pour moi en ce moment.

Je reposte ma proposition de solution pour une application de réaction isomorphe à partir de https://github.com/jaredpalmer/razzle/issues/477#issuecomment -363538712

Le concept principal consiste à utiliser un espace réservé au moment de la compilation qui est injecté au moment de l'exécution juste avant l'exécution du serveur afin de définir correctement les variables d'environnement d'exécution. Cette solution permet d'exécuter le serveur dans un conteneur Docker mais pourrait probablement être adaptée pour cette RFC.

Notez que dans cette solution, les variables d'environnement RAZZLE_XXXX sont mises en correspondance et injectées avec HOST, PORT et REDIS_URL.

J'ai personnellement lutté avec ce problème et j'ai passé plusieurs heures à trouver une solution à ce problème.

Ceci est inhérent à la compilation webpack et n'est pas lié au fait de s'énerver lui-même.

Après avoir examiné comment create-react-app gère cela et porté du code javascript et ruby ​​sur deux projets, j'ai déployé avec succès une application razzle typescript react dans un conteneur docker sur heroku avec la solution suivante :

env.ts

Ce script est utilisé comme module pour gérer l'environnement d'exécution.

export interface EnvironmentStore {
  NODE_ENV?: string;
  [key: string]: string | undefined;
}

// Capture environment as module variable to allow testing.
let compileTimeEnv: EnvironmentStore;
try {
  compileTimeEnv = process.env as EnvironmentStore;
} catch (error) {
  compileTimeEnv = {};
  // tslint:disable-next-line no-console
  console.log(
    '`process.env` is not defined. ' +
    'Compile-time environment will be empty.'
  );
}

// This template tag should be rendered/replaced with the environment in production.
// Padded to 4KB so that the data can be inserted without offsetting character
// indexes of the bundle (avoids breaking source maps).
/* tslint:disable:max-line-length */
const runtimeEnv = '{{RAZZLE_VARS_AS_BASE64_JSON__________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________}}';
/* tslint:enable:max-line-length */

// A function returning the runtime environment, so that
// JSON parsing & errors occur at runtime instead of load time.
export const loadRuntimeEnv = (): EnvironmentStore => {
  let env;
  if (typeof env === 'undefined') {
    if (compileTimeEnv.NODE_ENV === 'production') {
      try {
        env = JSON.parse((Buffer.from(runtimeEnv.trim(), 'base64').toString()));
      } catch (error) {
        env = {};
        const overflowsMessage = runtimeEnv.slice(32, 33) !== null;
        // tslint:disable-next-line no-console
        console.error(
          'Runtime env vars cannot be parsed. Content is `%s`',
          runtimeEnv.slice(0, 31) + (overflowsMessage ? '…' : '')
        );
      }

    } else {
      env = compileTimeEnv;
    }
  }
  return env;
};

export default loadRuntimeEnv;

usage:

import { loadRuntimeEnv, EnvironmentStore } from './env';
const env: EnvironmentStore = loadRuntimeEnv();

const serverHost: string =env.RAZZLE_SERVER_HOST || 'localhost';

docker-start.js

Ce script est utilisé comme point d'entrée au lieu de server.js et est utilisé pour injecter {{RAZZLE_VARS_AS_BASE64_JSON___... }} avec les variables d'environnement d'exécution réelles.

require('newrelic');
const logger = require('heroku-logger');
const path = require('path');
const fs = require('fs');

const PLACEHOLDER = /\{\{RAZZLE_VARS_AS_BASE64_JSON_*?\}\}/;
const MATCHER = /^RAZZLE_/i;

const InjectableEnv = {

    inject: function(file, ...args) {

        const buffer = fs.readFileSync(file, { encoding: 'utf-8' });
        let injectee = buffer.toString();

        const matches = injectee.match(PLACEHOLDER);
        if (!matches) {
            return;
        }

        const placeholderSize = matches[0].length;

        let env = InjectableEnv.create(args);
        const envSize = env.length;
        const newPadding = placeholderSize - envSize;
        if (newPadding < 0) {
            console.log('You need to increase your placeholder size');
            process.exit();
        }
        const padding = Array(newPadding).join(' ');
        env = InjectableEnv.pad(padding, env);

        const injected = injectee.replace(PLACEHOLDER, env);

        fs.writeFileSync(file, injected, { encoding: 'utf-8' });
    },

    create: function() {

        const vars = Object.keys(process.env)
            .filter(key => MATCHER.test(key))
            .reduce((env, key) => {
                env[key] = process.env[key];
                return env;
            }, {});

        vars.NODE_ENV = process.env.NODE_ENV;

        if (typeof process.env.HOST !== 'undefined' && typeof vars.RAZZLE_SERVER_HOST === 'undefined') {
          vars.RAZZLE_SERVER_HOST = process.env.HOST;
        }

        if (typeof process.env.PORT !== 'undefined' && typeof vars.RAZZLE_SERVER_PORT === 'undefined') {
          vars.RAZZLE_SERVER_PORT = process.env.PORT;
        }

        if (typeof process.env.REDIS_URL !== 'undefined' && typeof vars.RAZZLE_REDIS_URL === 'undefined') {
          vars.RAZZLE_REDIS_URL = process.env.REDIS_URL;
        }

        return Buffer.from(JSON.stringify(vars)).toString('base64');
    },

    pad: function(pad, str, padLeft) {
        if (typeof str === 'undefined')
            return pad;
        if (padLeft) {
            return (pad + str).slice(-pad.length);
        } else {
            return (str + pad).substring(0, pad.length);
        }
    }
}

const root = process.cwd();
const serverBundle = path.resolve(path.join(root, '/build/server.js'));

if (fs.existsSync(serverBundle)) {
    logger.info('Injecting runtime env');
    InjectableEnv.inject(serverBundle);
    logger.info('Launching server instance');
    require(serverBundle);
}

Dockerfile

# You should always specify a full version here to ensure all of your developers
# are running the same version of Node.
FROM node:8.9.4

ENV NODE_ENV=production \
    REACT_BUNDLE_PATH=/static/js/vendor.js \
    PATH=/app/node_modules/.bin:$PATH \
    NPM_CONFIG_LOGLEVEL=warn

RUN curl -o- -L https://yarnpkg.com/install.sh | bash

# use changes to package.json to force Docker not to use the cache
# when we change our application's nodejs dependencies:
COPY package.json yarn.lock /tmp/
RUN cd /tmp \
  && yarn install --production=false --pure-lockfile \
  && mkdir -p /app \
  && cp -a /tmp/node_modules /app \
  && yarn cache clean \
  && rm -rf *.*

# From here we load our application's code in, therefore the previous docker
# "layer" thats been cached will be used if possible
WORKDIR /app
ADD . /app

RUN yarn build

EXPOSE 3000

CMD ["node", "docker-start.js"]

Veuillez noter que le traitement du message de débordement n'est pas terminé, mais j'espère que cela vous aidera

Les références:

Heroku Buildpack pour create-react-app
Couche interne de Heroku Buildpack pour create-react-app

Ceci est inhérent à la compilation webpack et n'est pas lié au fait de s'énerver lui-même.

Razzle est celui qui configure DefinePlugin. Ceci peut être résolu dans Razzle.

Je pense que je suis ce que vous dites. Dites-moi si je me suis trompé : au moment de la construction, placez des espaces réservés dans process.env qui obtiennent la chaîne remplacée au démarrage de l'instance dans la construction du serveur. Il est destiné à gérer les secrets du serveur. (Je ne vois pas pourquoi il ne pourrait pas s'exécuter également sur la version client) Problèmes : cela ne fonctionnera pas avec HMR. C'est un hack -- il introduit une limite arbitraire de 4k. Dans sa forme actuelle, il n'adresse pas les variables d'environnement qui doivent être partagées avec le client -- celles-ci restent des constantes au moment de la construction. C'est une étape de démarrage supplémentaire pour les conteneurs.

Pour ressasser beaucoup de ce que j'ai dit dans https://github.com/jaredpalmer/razzle/issues/528#issuecomment -377058844

Je pense que la solution est de reconnaître que Razzle et CRA essaient d'intégrer plus de fonctionnalités dans process.env qu'il n'aurait dû. Pour le faire fonctionner avec Docker, nous essayons d'avoir un objet avec des champs ayant l'un des 4 états possibles : statique (temps de construction) et dynamique (ici, heure de début du conteneur), secrets et non-secrets. Nous pourrions proposer des préfixes pour ces 4 états (process.env.STATIC_PRIVATE_X, process.env.DYNAMIC_PUBLIC_Y, ...) mais je pense que nous serions bien mieux avec une solution plus propre.

Si process.env se comportait comme il le fait nativement - en tant que magasin de secrets de serveur - alors les choses sont beaucoup plus faciles à comprendre. Il y a une exception : NODE_ENV en tant qu'inline au moment de la construction, mais ce n'est pas grave car c'est une propriété de la construction. Cela n'aurait aucun sens de définir NODE_ENV au moment de l'exécution.

Il ne reste plus qu'un moyen d'acheminer les données vers le client. Je ne vois pas du tout pourquoi cela utilise process.env. Pourquoi ne pas utiliser, par exemple, razzle.build.X pour les éléments statiques et transmettre les éléments dynamiques au client de la même manière que redux ?

Il existe un autre problème où process.env est lent sur Node, mais il est préférable de le résoudre avec une couche de cache qui lit process.env une fois.

@gregmartyn Je suis d'accord qu'il s'agit d'un hack ... et cela introduit une limite 4K arbitraire. Cette idée est basée sur ce qui est actuellement fait avec CRA (voir les références publiées) et est destinée aux variables d'environnement d'exécution côté serveur.

Ouverture d'un PR qui, selon moi, devrait aider à résoudre ce problème - les vars env n'étant pas disponibles sur le serveur au moment de l'exécution, intéressé de savoir si cela résout certains des problèmes ici.

Je suis également d'accord que PORT & HOST seraient également idéalement laissés seuls au moment de la compilation du serveur.

@tgriesser sympa ! C'est une grande amélioration.
En plus de PORT et HOST , j'ajouterais PUBLIC_PATH à la liste des vars qui ne devraient pas être compilées.

Je trouve toujours que les variables d'environnement personnalisées sensibles sont toutes compilées dans le client. Je les référence uniquement dans server.js . Est-ce que razzle considère cela comme isomorphe à cause du hotloader ? Comment puis-je empêcher ceux-ci d'atteindre le client.

Salut tout le monde, je m'attaque à tout ça au travail cette semaine. Restez à l'écoute. #611 est susceptible d'être fusionné.

Suivre le nouveau guide dans le fichier readme avec config.js a fonctionné pour moi en ce qui concerne la suppression des variables d'environnement sensibles du bundle. Génial :D

Voir les notes de la v2

@jaredpalmer Il me manque peut-être quelque chose, mais c'est toujours un problème pour des choses comme PORT, malgré ce que la documentation readme implique. process.env.MY_THING fonctionne bien, mais process.env.PORT est toujours remplacé au moment de la construction et n'est pas lu au moment de l'exécution. Donc, l'exemple Heroku ne fonctionne pas réellement.

Je ne vois aucune gestion spéciale de PORT, HOST, etc., comme indiqué dans ce fil.

Notez que faire de PORT une vraie variable est également bloqué par #581. Je dois corriger cela et utiliser un razzle.config.js qui crée un tableau DefinePlugin qui supprime PORT afin de le faire fonctionner. (Mais, il fonctionne!)

si quelqu'un veut utiliser des variables .env au runtime, utilisez ce petit package.
https://www.npmjs.com/package/razzle-plugin-runtimeenv

Quelqu'un peut-il s'il vous plaît indiquer comment déployer l'application Razzle sur Azure ? J'ai vraiment du mal avec ça.

si quelqu'un veut utiliser des variables .env au runtime, utilisez ce petit package.
https://www.npmjs.com/package/razzle-plugin-runtimeenv

Comment ça marche? Pourrais-tu montrer un exemple ?

Je pense que les variables d'environnement devraient être injectées au moment de l'exécution en effet. Si nous contemplons une application razzle, nous aimerions créer une image indépendamment de l'environnement qu'elle exécute, et lire les variables d'environnement au démarrage du serveur et les servir ensuite à l'application cliente.

Toute autre approche n'utilise pas vraiment de variables d'environnement car cela ne se produit que pendant le temps de construction.

Comme je l'ai mentionné ici :
https://github.com/HamidTanhaei/razzle-plugin-runtime/issues/1#issuecomment -525731273

vous pouvez utiliser vos fichiers .env et .env.development dans le runtime par razzle-plugin-runtime . il ajoute la possibilité d'utiliser vos variables d'environnement dans votre application au moment de l'exécution.

par exemple, je l'utilise pour configurer axios :
axios.defaults.baseURL = ${process.env.RAZZLE_APP_API_BASE_PATH}${process.env.RAZZLE_APP_API_VERSION} ;
et vous pouvez fournir des variables ENV de production pour la production comme ceci :
https://github.com/jaredpalmer/razzle#adding -temporary-environment-variables-in-your-shell

Quelqu'un peut-il s'il vous plaît indiquer comment déployer l'application Razzle sur Azure ? J'ai vraiment du mal avec ça.

J'ai résolu le problème du port Azure à l'aide de la solution partagée par @fabianishere à l' adresse https://github.com/jaredpalmer/razzle/issues/906#issuecomment -467046269