Razzle: Variable d'environnement PORT en ligne compilée

Créé le 21 sept. 2017  ·  13Commentaires  ·  Source: jaredpalmer/razzle

En raison de la façon dont getClientEnvironment est écrit, la variable d'environnement PORT est intégrée dans la version finale au lieu d'être conservée sous la forme process.env.PORT .

Cela entraînera l'échec du lancement de Razzle sur Heroku en utilisant start:prod

stale

Commentaire le plus utile

J'ai trouvé une solution de contournement assez simple à ce problème, si les gens sont toujours aux prises avec cela

  // This will extract the env during production execution.. PORT will not be inlined during build
  const getEnv = c => process.env[c];
  app.listen(getEnv('PORT'));

Tous les 13 commentaires

J'ai également remarqué que la façon dont la fonction getClientEnvironment stringified est écrite, l'intégralité de process.env est remplacée par un objet en ligne comprenant toutes les variables d'environnement :

// console.log(process.env.PORT) gets compiled to:
console.log(Object({"NODE_ENV":"production","PORT":3000,"VERBOSE":false,"HOST":"localhost","RAZZLE_ASSETS_MANIFEST":"somepath","BUILD_TARGET":"server","RAZZLE_PUBLIC_DIR":"somepath"}).PORT);

Cela rend impossible de rendre la configuration de l'application serveur dynamique sans la reconstruire à chaque fois.

Salut @d4rky-pl,
Vous pouvez utiliser razzle-heroku :) Il étend la configuration par défaut de razzle pour qu'elle fonctionne sur heroku.
Voir #340 pour plus d'infos

@xouabita c'est gentil, merci :)

Je pense que Razzle devrait prendre en charge cela par défaut ou avoir une mise en garde à propos de process.env et de la construction de la production dans un endroit plus important.

Cela s'avère encore plus problématique que je ne l'imaginais. Laissez-moi expliquer:

J'écris un lanceur de tests système (tests système : tests qui s'exécutent dans le navigateur réel) et je souhaite ajouter la prise en charge de razzle dès le premier jour. Le problème est que, parce que PORT est intégré dans la construction résultante, je dois également l'intégrer lors de la compilation de tout avant de tester.

Cela peut causer une confusion inutile lorsque quelqu'un essaie ensuite d'utiliser la même version pour autre chose (c'est la version de production après tout, à part PORT, il n'y a aucun changement) car le PORT en ligne dans les tests est différent de celui lors de la compilation de production "normale". . Je pourrais également supprimer la version après avoir exécuté des tests, mais cela interrompra le flux où nous effectuons des tests système avant le déploiement en production, puis réutiliserons le même code compilé.

@jaredpalmer, veuillez reconsidérer la décision d'intégrer PORT dans la version de production et d'ajouter une recherche unique (quelque chose comme const PORT = process.env.PORT au début de server.js) à la place. S'il n'y a aucune chance en enfer pour cela, veuillez fermer ce problème et j'ajouterai un avertissement dans mon outil :)

@d4rky-pl faisons les choses correctement.

et si on mettait sur liste noire

  • process.env.RAZZLE_SERVER_ ne sera pas compilé
  • et PORT

Je suis sûr que vous le savez probablement, mais la lecture de process.env. pendant l'exécution est incroyablement lente et doit être évitée autant que possible. Cependant, ce serait mieux si razzle était plus facilement déployable sur heroku, etc. alors oui. découvrons cela.

J'aime ça. Dans le cas de PORT les performances ne devraient pas être un problème, cette variable d'environnement n'est lue que pendant le démarrage.

En ce qui concerne RAZZLE_SERVER_ , cela semble être une bonne solution de contournement pour ces quelques cas supplémentaires, bien que je ne sois pas sûr du nom - cela peut prêter à confusion et entraîner une diminution des performances lorsque les gens supposent que c'est ainsi que vous devez tout définir variables d'environnement côté serveur (au lieu de celles que vous souhaitez réellement remplacer lors du démarrage de l'application). J'ai bien peur de ne pas avoir de meilleure option.

J'ai eu le même problème, cela se produit également avec des vars env non définies au moment de la construction. Voici la solution de contournement :

/* eslint-disable no-param-reassign */
const razzleConfigEnv = require('razzle/config/env');

module.exports = {
  modify: (config, { target, dev }, webpack) => {
    // Fix process.env
    if (target === 'node') {
      config.plugins = config.plugins.filter(plugin => plugin.constructor.name !== 'DefinePlugin');
      const dotenv = razzleConfigEnv.getClientEnv(target, {
        clearConsole: true,
        host: 'localhost',
        port: 3000
      });
      config.plugins.push(
        new webpack.DefinePlugin({
          'process.env': `Object.assign(${JSON.stringify(dotenv.raw)}, process.env)`
        })
      );
    }
    return config;
  }
};

Voici ma solution de contournement pour Heroku :

// getPorts.js

// bypass webpack.DefinePlugin
const { env } = require('process')

export const port = () =>
  parseInt(
    env.RAZZLE_PORT ||
      env.PORT ||
      process.env.RAZZLE_PORT ||
      process.env.PORT ||
      3000,
    10,
  )

Hola ! Alors voici l'accord, entre l'open source et mon travail et ma vie quotidienne et que sais-je encore, j'ai beaucoup de choses à gérer, alors j'utilise un bot GitHub pour automatiser quelques choses ici et là. Ce bot GitHub particulier va marquer cela comme obsolète car il n'a pas eu d'activité récente depuis un certain temps. Il sera fermé s'il n'y a plus d'activité dans quelques jours. Ne prenez pas cela personnellement - au sérieux - il s'agit d'une action entièrement automatisée. S'il s'agit d'une erreur, faites simplement un commentaire, envoyez-moi un DM, envoyez un pigeon voyageur ou un signal de fumée.

ProBot a automatiquement fermé cela en raison de l'inactivité. Holler si c'est une erreur, et nous la rouvrirons.

J'ai trouvé une solution de contournement assez simple à ce problème, si les gens sont toujours aux prises avec cela

  // This will extract the env during production execution.. PORT will not be inlined during build
  const getEnv = c => process.env[c];
  app.listen(getEnv('PORT'));

J'ai eu le même problème, cela se produit également avec des vars env non définies au moment de la construction. Voici la solution de contournement :

/* eslint-disable no-param-reassign */
const razzleConfigEnv = require('razzle/config/env');

module.exports = {
  modify: (config, { target, dev }, webpack) => {
    // Fix process.env
    if (target === 'node') {
      config.plugins = config.plugins.filter(plugin => plugin.constructor.name !== 'DefinePlugin');
      const dotenv = razzleConfigEnv.getClientEnv(target, {
        clearConsole: true,
        host: 'localhost',
        port: 3000
      });
      config.plugins.push(
        new webpack.DefinePlugin({
          'process.env': `Object.assign(${JSON.stringify(dotenv.raw)}, process.env)`
        })
      );
    }
    return config;
  }
};

J'ai essayé ceci, mais lorsque j'essaie 'npm run start:prod ' sur mon local, j'obtiens une erreur que assets.json n'est pas trouvé. En outre, pourriez-vous s'il vous plaît indiquer, dois-je télécharger node_modules dans le dossier de construction ainsi que je reçois également des erreurs liées au package npm.

Cela fonctionne pour moi maintenant.

`
appConfig.plugins = appConfig.plugins.filter(plugin => plugin.constructor.name !== 'DefinePlugin');
const dotenv = razzleConfigEnv.getClientEnv(cible);

  delete dotenv.raw.PORT;
  config.plugins.push(
    new webpack.EnvironmentPlugin(dotenv.raw)
  );

`

Cette page vous a été utile?
0 / 5 - 0 notes

Questions connexes

corydeppen picture corydeppen  ·  3Commentaires

krazyjakee picture krazyjakee  ·  3Commentaires

pseudo-su picture pseudo-su  ·  3Commentaires

gabimor picture gabimor  ·  3Commentaires

dizzyn picture dizzyn  ·  3Commentaires