Ich persönlich würde mir keine Sorgen machen, dass process.env auf dem Client nicht verfügbar ist. Wir müssen bereits wissen, dass 'window' auf dem Server nicht verfügbar ist; es macht für mich Sinn, dass process.env das gegenteilige Verhalten hätte. (es gibt keinen Node-Prozess, für den man eine Umgebung haben muss, und Browser legen ihre env-Variablen nicht offen, die mir bekannt sind) Ich stelle mir process.env als einen Ort vor, an dem Servergeheimnisse enden können, also wäre es mir lieber auf der Client-Seite standardmäßig nicht verfügbar.

Wenn es nach mir ginge, würden die Variablen process.env.RAZZLE_INLINED_XXXXXX während des Builds einkompiliert (und auf dem Client als Inline-DefinePlugin-Strings verfügbar sein) und alles andere wäre nur auf der Serverseite verfügbar.

NODE_ENV könnte auch inline eingefügt werden, da es hauptsächlich als Beschreibung des Builds verwendet wird und nicht als etwas Variables wie die Umgebung, in der der Code ausgeführt wird. Es gibt auch einige Leistungsgründe dafür.

Ich mag die Idee, dass PORT und HOST zur Laufzeit variabel sind. Ich kann die gleichen Build-Artefakte in verschiedenen Umgebungen ausführen.

Ich kann den Kampf bestätigen. Das aktuelle Verhalten war nicht das, was ich erwartet hatte, und hat mich besonders beim Deployment mit up auf aws gestolpert. Ich habe jetzt razzle.config.js so angepasst, dass alle razzle-spezifischen Variablen das Präfix RAZZLE_XXX und diese zur Kompilierzeit stringifiziert werden. Der Rest ist auf process.env.XXX . Ich stimme @gregmartyn auch zu, dass Laufzeitvariablen bis process.env nicht verfügbar sind.

Als wir versuchten, Razzle in einem bestehenden React-Projekt einzurichten, waren wir mit diesem Problem konfrontiert. Der Port ist zur Laufzeit nicht überschreibbar und andere process.env-Variablen sind auf dem Server nicht verfügbar.

Aktuelles Verhalten zur Build-Zeit:

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

wird auf Client und Server:

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

Dadurch wird zwar sichergestellt, dass Client und Server genau die gleichen Prozessumgebungen verwenden können, jedoch ist es dadurch unmöglich, zur Laufzeit zu überschreiben oder andere Umgebungsvariablen zu verwenden.

Wenn Sie vollständig abwärtskompatibel sein möchten, sollte es in der Build-Zeit darauf transpiliert werden (auf dem Server kann der Client gleich bleiben):

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

Auf diese Weise können Sie process.env.PORT sowohl auf dem Client als auch auf dem Server verwenden. Der Standardwert ist 3000.

Wenn razzle mit PORT=80 _gebaut_ ist, hat der Client process.env.PORT auf 80 transpiliert und der Server lässt es auf process.env.PORT || 80 transpilieren. Dies führt zu dem gleichen Verhalten, wie es jetzt ist.

Wenn razzle mit PORT=81 _run_ ist (während es mit 80 ), bleibt die Umgebungsvariable des Clients 80 während die Servervariable 81 ergibt.

Dieses Verhalten kann natürlich zu unerwartetem Verhalten führen, bietet jedoch die flexibelste Nutzung von process.env bei gleichzeitiger Beibehaltung der vollständigen Abwärtskompatibilität. Der Port kann weiterhin zur Laufzeit auf dem Server überschrieben werden, und andere Umgebungsvariablen, die von Hosting-Plattformen festgelegt werden, funktionieren unverändert auf dem Server.

Ich denke, das zugrunde liegende Problem hier ist, dass Razzle derzeit versucht, mehrere unterschiedliche Funktionen in ein Objekt zu packen und bestehende Funktionen grundlegend zu ändern.

Es versucht:

1. Verwandeln Sie process.env-Variablen aus Leistungsgründen in Konstanten (siehe Minimierungsbeispiel auf https://webpack.js.org/plugins/define-plugin/#usage und nodejs slowness unter https://github.com/nodejs/node/issues /3104)
2. Stellen Sie diese Konstanten sowohl dem Server als auch dem Client zur Verfügung, damit sich isometrischer Code weniger Sorgen machen muss.

Probleme:

• process.env ist für die Umgebung _variables_. Wenn Sie es in einen Satz von Konstanten umwandeln, ändert sich das erwartete Verhalten.
• process.env enthält oft sensible Informationen einschließlich Passwörtern, daher ist es keine gute Quelle für Daten, die mit dem Client geteilt werden können. Wenn es teilweise geteilt und teilweise nicht geteilt wird, muss der Entwickler wissen, dass sich diese eine Sache -- process.env -- nicht nur nicht wie nativ verhält, sondern auch je nach Schlüsselpräfixen ein anderes Verhalten hat.
• Sie wird zur Build-Zeit in Konstanten umgewandelt, was sich von dem Verhalten von Umgebungsvariablen in anderen Kontexten unterscheidet. Docker unterscheidet beispielsweise zwischen Build-Time-Variablen (nützlich, wenn der Build selbst variable Informationen erfordert, je nachdem, wo er ausgeführt wird) und Umgebungsvariablen (nützlich, wenn ein vorgefertigtes Image in verschiedenen Umgebungen bereitgestellt wird). Elastische Bohnenranke, Heroku et al. das Gleiche tun.
• Das vorgeschlagene Präfix "RAZZLE_RUNTIME_" ist nicht selbsterklärend. Es sollte vermitteln, dass es clientseitig verfügbar ist und keine Variable ist. Ich denke, "INLINED_" deckt das ab, da Inlining häufig verwendet wird, um sich auf etwas zu beziehen, das zur Build-Zeit passiert. Es ist nicht perfekt ("ISOMORPHIC_INLINED_"?), aber es versucht auch, kurz zu sein.

Ich bevorzuge es, diese Funktionalität in verschiedene Teile aufzuteilen und die Datei process.env überhaupt nicht zu manipulieren.
Das DefinePlugin könnte eine Datei wie razzle.config.js aufrufen, um die Build-Konstanten abzurufen
Empfehlen Sie die Verwendung eines Musters, das dem von Redux mit configureStore(window.__PRELOADED_STATE__) ähnelt, um Daten vom Server an den Client zu übergeben.

Aus Gründen der Abwärtskompatibilität könnten die Upgrade-Hinweise ein Beispiel für razzle.config.js bereitstellen, das die Definitionen auf die altmodische Weise übernimmt.

Ein Nachtrag: Ich sagte, "process.env überhaupt nicht zu manipulieren." aber ich konnte aus meinem obigen Kommentar aus Performancegründen eine Ausnahme für process.env.NODE_ENV sehen und dass "NODE_ENV" selbst im Allgemeinen die Bedeutung von "NODE_ENV = Produktion bedeutet, dass dies ein optimierter Build ist" angenommen hat.

@gregmartyn wir müssen NODE_ENV für Leistungsoptimierungen setzen und das Babel-Preset verwenden, wie es jetzt funktioniert. Mein erster Grund für das Durcheinander mit env war, den Wechsel von CRA viel einfacher zu machen, da SSR oft hinzugefügt wird, nachdem ein Projekt bereits begonnen hat. Wir verwenden CRA auch bei anderen Projekten, sodass unsere Build-Tools (etwas) vereinfacht werden.

Ja; stimmte darin überein, dass NODE_ENV eine sinnvolle Ausnahme ist. Es ist seine eigene Sache und eng mit dem Build verbunden, daher ist es nicht verwunderlich. Ich habe CRA von einer benutzerdefinierten SSR-Lösung direkt übersprungen, daher bin ich nicht wirklich damit vertraut, wie sie Dinge tun. Es sieht so aus, als ob dies auch dort ein Problem wäre: https://github.com/facebook/create-react-app/issues/2353

Ich denke, dies ist für Razzle ein größeres Problem als für CRA, da der Laufzeitcode in einer CRA-App überhaupt nicht auf dem Server ausgeführt wird. CRA kann mit process.env tun, was immer sie will, denn was ihren clientseitigen Code betrifft, wäre sie sonst leer. Razzle hingegen startet Express für sein SSR, und dieser Code würde vernünftigerweise erwarten, dass process.env seine übliche Semantik mit Zugriff auf den vollständigen Satz von Knotenlaufzeitumgebungsvariablen hat. Process.env hat auf dem Server eine tatsächliche Bedeutung, daher ist es bedauerlich, dass CRA es für einen anderen Anwendungsfall übernommen hat. Sie hätten einen anderen Namen anstelle von "process.env" wie "cra.inlines" verwenden können. Stattdessen wird isomorpher Code von einer Entscheidung getroffen, die getroffen wurde, wenn nur die Client-Seite berücksichtigt wurde.

Überall ist rot zu vermerken, dass RAZZLE_XXX Umgebungsvariablen ALLE auf dem Client zur Verfügung gestellt werden.

Wie verwende ich sensible Umgebungsvariablen, ohne dass sie an den Client gesendet werden?

Sie werden nicht an den Client gesendet, es sei denn, Sie verweisen auf sie in isomorphem Code

@jaredpalmer vielleicht ist dieses Problem dann spezifisch für Afterjs? Ich verweise nur im Servercode auf sie.

Ich möchte eine Stimme für die Möglichkeit abgeben, Umgebungsvariablen ohne das Präfix RAZZLE zu definieren. Zumindest sollte process.env nicht serverseitig gelöscht werden, was Sie daran hindert, so etwas wie dotenv zum Laden serverseitiger env-Variablen zu verwenden. Dies scheint eine viel zu aufdringliche Annahme über die Anwendungsumgebung zu sein.

Mir ist nicht ganz klar, wie razzle derzeit Umgebungsvariablen in den Client und den Server einfügt, aber Sie möchten sicherlich keine serverspezifischen Dinge auf dem Client. Leider ist dies im Moment eine Art Deal-Breaker für mich.

Ich poste meinen Lösungsvorschlag für eine isomorphe Reaktions-App von https://github.com/jaredpalmer/razzle/issues/477#issuecomment -363538712

Das Hauptkonzept besteht darin, zur Kompilierzeit einen Platzhalter zu verwenden, der zur Laufzeit kurz vor der Serverausführung eingefügt wird, um Laufzeitumgebungsvariablen richtig einzustellen. Diese Lösung dient zum Ausführen des Servers in einem Docker-Container, könnte aber wahrscheinlich für diesen RFC angepasst werden.

Beachten Sie, dass in dieser Lösung die Umgebungsvariablen RAZZLE_XXXX abgeglichen und zusammen mit HOST, PORT und REDIS_URL eingefügt werden.

Ich habe persönlich mit diesem Problem gekämpft und mehrere Stunden damit verbracht, eine Lösung für dieses Problem zu finden.

Dies ist inhärent mit der Webpack-Kompilierung und hat nichts mit Razzle selbst zu tun.

Nachdem ich mir angeschaut habe, wie create-react-app dies handhabt, und etwas Javascript- und Ruby-Code in zwei Projekten portiert habe, habe ich erfolgreich eine Razzle Typescript React-App in einem Docker-Container auf heroku mit der folgenden Lösung bereitgestellt:

env.ts

Dieses Skript wird als Modul verwendet, um die Laufzeitumgebung zu handhaben.

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;

Verwendungszweck:

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

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

docker-start.js

Dieses Skript wird als Einstiegspunkt anstelle von server.js verwendet und wird verwendet, um {{RAZZLE_VARS_AS_BASE64_JSON___... }} Placehoder mit den tatsächlichen Laufzeitumgebungsvariablen einzufügen.

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"]

Bitte beachten Sie, dass die Verarbeitung der Überlaufmeldung noch nicht abgeschlossen ist, aber ich hoffe, das hilft

Verweise:

Heroku Buildpack für Create-React-App
Innere Schicht von Heroku Buildpack für Create-React-App

Dies ist inhärent mit der Webpack-Kompilierung und hat nichts mit Razzle selbst zu tun.

Razzle ist derjenige, der DefinePlugin einrichtet. Dies ist in Razzle lösbar.

Ich glaube, ich kann deiner Aussage folgen. Sagen Sie mir, wenn ich das falsch verstanden habe: Fügen Sie zur Build-Zeit Platzhalter in process.env ein, die beim Start der Instanz im Server-Build ersetzt werden. Es ist dazu gedacht, Servergeheimnisse zu handhaben. (Ich verstehe jedoch nicht, warum es nicht auch auf dem Client-Build ausgeführt werden konnte) Probleme: Es funktioniert nicht mit HMR. Es ist ein Hack – er führt eine willkürliche 4k-Grenze ein. In seiner aktuellen Form adressiert es keine Umgebungsvariablen, die mit dem Client geteilt werden müssen – diese bleiben Build-Time-Konstanten. Dies ist ein zusätzlicher Startschritt für Container.

Um vieles von dem wieder aufzuwärmen, was ich in https://github.com/jaredpalmer/razzle/issues/528#issuecomment -377058844 gesagt habe

Ich denke, die Lösung besteht darin, zu erkennen, dass Razzle und CRA versuchen, mehr Funktionen in process.env zu packen, als sie haben sollten. Damit es mit Docker funktioniert, versuchen wir, ein Objekt mit Feldern zu haben, die einen von 4 möglichen Zuständen haben: statisch (Buildzeit) und dynamisch (hier Containerstartzeit), Geheimnisse und Nicht-Geheimnisse. Wir könnten uns Präfixe für alle 4 dieser Zustände einfallen lassen (process.env.STATIC_PRIVATE_X, process.env.DYNAMIC_PUBLIC_Y, ...), aber ich denke, wir wären mit einer saubereren Lösung viel besser dran.

Wenn sich process.env so verhalten würde, wie es sich nativ verhält – als Speicher für Servergeheimnisse –, dann sind die Dinge viel einfacher zu verstehen. Es gibt eine Ausnahme: NODE_ENV als Build-Time-Inline, aber das ist in Ordnung, da es eine Eigenschaft des Builds ist. Es wäre nicht sinnvoll, NODE_ENV zur Laufzeit zu setzen.

Es bleibt nur noch eine Möglichkeit, Daten an den Client zu übermitteln. Ich verstehe nicht, warum dies überhaupt process.env verwendet. Warum nicht zB razzle.build.X für statisches Zeug verwenden und dynamisches Zeug auf die gleiche Weise wie Redux an den Client übergeben?

Es gibt noch ein weiteres Problem, bei dem process.env auf Node langsam ist, aber das lässt sich am besten mit einer Cache-Schicht beheben, die process.env einmal liest.

@gregmartyn Ich stimme zu, dass dies ein Hack ist ... und es führt eine willkürliche 4K-Grenze ein. Diese Idee basiert auf dem, was derzeit mit CRA gemacht wird (siehe die veröffentlichten Referenzen) und ist für serverseitige Laufzeitumgebungsvariablen gedacht.

Ich habe eine PR geöffnet , von der ich glaube, dass sie bei dieser Wurzel dieses Problems helfen sollte - env ​​vars sind zur Laufzeit auf dem Server nicht verfügbar, interessiert zu hören, ob dies einige der Probleme hier löst.

Ich stimme auch zu, dass PORT & HOST auch idealerweise während der Serverkompilierung in Ruhe gelassen würden.

@tgriesser schön! Das ist eine große Verbesserung.
Zusätzlich zu PORT und HOST würde ich PUBLIC_PATH zur Liste der Variablen hinzufügen, die nicht einkompiliert werden sollen.

Ich finde immer noch, dass alle sensiblen benutzerdefinierten Umgebungsvariablen in den Client kompiliert werden. Ich verweise nur in server.js auf sie . Hält razzle dass isomorph wegen der hotloader ? Wie kann ich verhindern, dass diese den Client erreichen.

Hallo zusammen, ich werde das alles diese Woche bei der Arbeit in Angriff nehmen. Bleiben Sie dran. #611 wird wahrscheinlich zusammengeführt.

Das Befolgen der neuen Anleitung in der Readme mit config.js hat für mich in Bezug auf das Entfernen sensibler Umgebungsvariablen aus dem Bundle funktioniert. Genial :D

Siehe v2-Notizen

@jaredpalmer Ich process.env.MY_THING funktioniert gut, aber process.env.PORT wird immer noch zur Build-Zeit ersetzt und zur Laufzeit nicht gelesen. Das Heroku-Beispiel funktioniert also nicht wirklich.

Ich sehe keine spezielle Behandlung von PORT, HOST usw., wie in diesem Thread besprochen.

Beachten Sie, dass die PORT-Variable auch von #581 blockiert wird. Ich muss das patchen und eine razzle.config.js verwenden, die ein DefinePlugin-Array erstellt, das PORT entfernt, damit es funktioniert. (aber es funktioniert!)

Wenn jemand .env-Variablen zur Laufzeit verwenden möchte, verwenden Sie dieses kleine Paket.
https://www.npmjs.com/package/razzle-plugin-runtimeenv

Kann mir jemand sagen, wie Sie die Razzle-App in Azure bereitstellen? Ich kämpfe wirklich damit.

Wenn jemand .env-Variablen zur Laufzeit verwenden möchte, verwenden Sie dieses kleine Paket.
https://www.npmjs.com/package/razzle-plugin-runtimeenv

Wie funktioniert es? Könnten Sie ein Beispiel zeigen?

Ich denke, Umgebungsvariablen sollten tatsächlich zur Laufzeit eingefügt werden. Wenn wir eine Razzle-App konteinerieren, möchten wir unabhängig von der Umgebung, in der sie ausgeführt wird, ein Image erstellen und die Umgebungsvariablen beim Starten des Servers lesen und sie dann der Client-App bereitstellen.

Jeder andere Ansatz verwendet nicht wirklich Umgebungsvariablen, da dies nur während der Buildzeit geschieht.

Wie ich hier erwähnt habe:
https://github.com/HamidTanhaei/razzle-plugin-runtime/issues/1#issuecomment -525731273

Sie können Ihre .env- und .env.development-Dateien in der Laufzeit von razzle-plugin-runtime . Es bietet die Möglichkeit, Ihre env-Variablen in Ihrer App zur Laufzeit zu verwenden.

zum Beispiel verwende ich es, um axios zu konfigurieren:
axios.defaults.baseURL = ${process.env.RAZZLE_APP_API_BASE_PATH}${process.env.RAZZLE_APP_API_VERSION} ;
und Sie können Produktions-ENV-Variablen für die Produktion wie folgt bereitstellen:
https://github.com/jaredpalmer/razzle#adding -temporary-environment-variables-in-your-shell

Kann mir jemand sagen, wie Sie die Razzle-App in Azure bereitstellen? Ich kämpfe wirklich damit.

Ich habe das Problem mit dem Azure-Port mit der von @fabianishere geteilten https://github.com/jaredpalmer/razzle/issues/906#issuecomment -467046269 gelöst