Next.js: .jsx-Erweiterung im Webpack auflösen

Interessant. Woher haben Sie die Information, dass .jsx die empfohlene Erweiterung ist? Ich habe schnell bei Google gesucht, aber keine offiziellen Kommentare dazu gefunden. Ich muss zugeben, dass mein Google Foo nicht das Beste ist.

Ja, ich bevorzuge .jsx einfach für die automatische Sprachauswahl in Editoren.

Aus dem Airbnb-Styleguide, der eigentlich der am

@7s4r Ok, ich kenne den Airbnb-Styleguide. Worauf ich gewartet habe, war ein Kommentar direkt von Facebook oder Babel. Aber sicher ist der Airbnb-Styleguide ein guter Punkt. Vielleicht wäre es der richtige Weg, beides zu unterstützen. Sie haben dies bereits in der Beschreibung des Problems erwähnt. Das bekommt also ein :+1: von mir :).

Ein weiterer Punkt, der für die Unterstützung der Erweiterung .jsx spricht, ist, dass TypeScript immer dann in diese Erweiterung kompiliert wird, wenn Sie ES6/ES2015 anvisieren

airbnb / eslint-plugin-react beschwert sich über die Regel " react/jsx-filename-extension"

Da die Webpack-Konfiguration jetzt manipuliert werden kann, ist dies möglich https://github.com/zeit/next.js#customizing -webpack-config

Gibt es ein Beispiel dafür, wie dies mit next.config.js funktioniert? Soweit ich das beurteilen kann, würde dies das Überschreiben von mindestens vier vom Framework erzeugten Loadern erfordern ( babel-loader , hot-self-accept-loader , react-hot-loader/webpack und emit-file-loader ). diese Dokumente werden ausdrücklich als schlechte Idee bezeichnet und verfehlen den Zweck des Frameworks.

Ich bin damit einverstanden, dass dies nicht unterstützt wird, wenn dies die offizielle Haltung ist, aber der obige Kommentar scheint darauf hinzudeuten, dass dies der Fall ist.

@AlteredConstants etwa so:

module.exports = {
  webpack: (config, { dev }) => {
    config.resolve.extensions = ['', '.js', '.jsx'];
    return config;
  }
}

_Allerdings_, nachdem ich dies gerade ausprobiert habe, sieht es so aus, als ob dieser Ansatz nicht funktioniert . Ich muss nachforschen, um herauszufinden, warum.

@rossipedia , damit Webpack importierte Module mit einer .jsx-Erweiterung nur erkennen kann, wenn die Erweiterung vom Import ausgeschlossen ist, zB import Foo from './Foo' statt import Foo from './Foo.jsx' .

Damit Webpack diese Module korrekt verarbeitet, müssen Sie (vermutlich) .jsx zur Eigenschaft test der oben erwähnten Loader hinzufügen. Das fühlt sich etwas schwerfällig und fehleranfällig an und behandelt den vorgerenderten Fall gemäß den oben verlinkten Dokumenten nicht. Ich bin mir auch nicht sicher, ob der automatische page/ Import in diesem Fall überhaupt funktioniert – das scheint außerhalb des Webpack-Prozesses und/oder vielleicht als separate Einstiegspunkte zu passieren?

Verständlicherweise ist die Modulauflösung in diesem Framework komplizierter als eine einfache Webpack-Konfigurationsoption. Also, wenn ich mich nicht irre, scheint die Lösung dieses Problems eher "wird nicht behoben" als "Workaround" zu sein, und ich wollte nur die Haltung des Teams klarstellen. @impronunciable , weitere Erkenntnisse?

Sollte dies zu FAQ hinzufügen.

module.exports = {
  webpack: (config) => {
    config.resolve.extensions = ['.js', '.jsx'];
    config.module.rules.push(
      {test: /\.(js|jsx)$/, use: 'babel-loader'}
    );
    return config;
  }
}

@JF-Liu funktioniert nicht für mich.

Ich bekomme Error: Cannot find module '../components/Page' oder Module build failed: Error: Couldn't find preset "stage-3" relative to directory "/Users/cla/Projects/with-mobx/node_modules/styled-jsx"

Versuch, next.js 2-beta + mobx + airbnb einzurichten

Vielleicht vermisse ich etwas? Was ist dein .babelrc Inhalt?

Es scheint auch, dass pages Erweiterungen nicht .jsx

@foxhound87 ja, das geht nicht, ich gebe auch auf.

TypeScript 2.2 unterstützt jetzt "jsx": "react-native" , wodurch .js Dateien ausgegeben werden, aber auch JSX erhalten bleibt. Siehe hier

gleiches problem hier :<, irgendwelche ideen, wie man das lösen kann?

Ich bin darauf gestoßen, als ich einen Bake-Off geschrieben habe, da unser Unternehmensstandard darin besteht, .jsx für alle Dateien zu verwenden, die jsx-Markup enthalten. Wenn Sie wissen, dass dies eine Webpack-Konfiguration ist und die Leistung nicht beeinträchtigen sollte, gibt es einen Grund, warum Next.js keine jsx-Importe unterstützt?

_Bearbeiten:_
Wie oben erwähnt, funktioniert die Verwendung der Webpack-Konfiguration gut zum Importieren von Komponenten, aber Dateien in /pages/ müssen die Erweiterung .js haben, um korrekt weitergeleitet zu werden. So albern dieses Thema auch erscheinen mag, große Teams müssen die aufgestellten Standards/Konventionen befolgen, damit dies die Annahme dieses großartigen Rahmens blockieren kann.

Ich mag alles an Next wirklich, abgesehen davon, was uns leider ausschließt, es zu verwenden.
Ich melde mich aber nochmal, um zu sehen, ob Fortschritte gemacht werden.

Das Problem scheint viel tiefer zu reichen als Webpack und Babel; es ist an zahlreichen Stellen fest codiert. :(

Die einzige Anstrengung, die ich bisher unternommen habe, war das Hinzufügen einer Zeile für "jsx" in server/resolve.js:34 . Ich tue dies, indem ich Dateien unter node_modules/next/dist/ meines Projekts

Wenn Sie die Änderung vornehmen, wird Folgendes in der Konsole ausgegeben. Beachten Sie, dass die Konsole jetzt Building page: / anstelle von Client pings, but there's no entry for page: / sagt.

 DONE  Compiled successfully in 12156ms                                                    8:34:44 PM

> Ready on http://localhost:3000
> Building page: /


 DONE  Compiled successfully in 10983ms                                                    8:34:58 PM

SyntaxError: Unexpected token m in JSON at position 0
    at JSON.parse (<anonymous>)
    at _callee$ (/Users/Jason/Repositories/radioapp/node_modules/next/dist/server/read-page.js:48:32)
    at tryCatch (/Users/Jason/Repositories/radioapp/node_modules/regenerator-runtime/runtime.js:64:40)
    at Generator.invoke [as _invoke] (/Users/Jason/Repositories/radioapp/node_modules/regenerator-runtime/runtime.js:299:22)
    at Generator.prototype.(anonymous function) [as next] (/Users/Jason/Repositories/radioapp/node_modules/regenerator-runtime/runtime.js:116:21)
    at step (/Users/Jason/Repositories/radioapp/node_modules/babel-runtime/helpers/asyncToGenerator.js:17:30)
    at /Users/Jason/Repositories/radioapp/node_modules/babel-runtime/helpers/asyncToGenerator.js:28:13

Bearbeiten:

Dieses Problem ist für mich eigentlich erträglich, da ich einfach ein server Verzeichnis mit einer .eslintrc Datei erstellt habe:

{
  "parser": "espree",
  "parserOptions": {
    "ecmaVersion": 6,
  },

  "env": {
    "node": true
  },
}

Falls es jemandem hilft, können Sie verschiedene Linter- und auch Sublime- Einstellungen pro Verzeichnis konfigurieren. Sie können auch ein public Verzeichnis erstellen, das Ihre Next.js-Dateien enthält, und die entsprechende .eslintrc Datei dort ablegen.

Ich verwende Sublime, mit babel-sublime und SublimeLinter-contrib-eslint .

@jasonszhao Ich stimme zu. Aber es ist unwahrscheinlich, dass wir .jsx Unterstützung unterstützen werden. Verwenden Sie die Erweiterung .js .

@arunoda Das ist schade. Viele von uns können es aufgrund dieser willkürlichen Designwahl nicht verwenden. Ich schätze, ich deinstalliere.

Wäre es nicht sinnvoller, es konfigurierbar zu machen? Verwenden Sie next.config.js und haben Sie eine Option, die standardmäßig ['.js'] , oder noch besser eine Funktion, die Dinge wie .test.js oder .spec.js für Jest herausfiltern kann.

BEARBEITEN: Ich versuche, .tsx da ich den tsc Ansatz im TypeScript-Beispiel nicht verwenden kann, da ich versuche, auch einen benutzerdefinierten Server in TypeScript auszuführen.

Wird .jsx immer noch nicht unterstützt? Ich stoße auch auf ein Problem, das mein Unternehmen von der Verwendung von next.js blockieren würde, da unser Standard darin besteht, .jsx für React-Komponenten zu verwenden.

Ich weiß, dass dies trivial erscheint, aber es macht es unserem Team wirklich schwer, die Annahme von Next zu rechtfertigen:(

Wäre toll, wenn jemand aus dem Kernteam diese scheinbar nicht konsequente Designentscheidung etwas näher erläutern könnte.

+1 für Unterstützung der .jsx-Erweiterung

Sie können problemlos .jsx-Unterstützung hinzufügen, aber ... nicht für SSR. Sie erhalten eine Fehlermeldung, aber nachdem Sie etwas im Code geändert und neu geladen haben, sehen Sie Ihre Seite. F5 und Boom, Fehler.

Nicht sicher, wie man das beheben kann.

const originalJS = "/\\.js(\\?[^?]*)?$/";

config.resolve.extensions = [".js", ".jsx", ".json"];
config.module.rules.forEach((rule) => {
    if (String(rule.test) === originalJS) {
        rule.test = /\.jsx?(\?[^?]*)?$/;
    }
});

Wie viele verstehe ich nicht, warum das nicht passieren kann.

Viele Leute verwenden eine Linter-Konfiguration, die besagt, dass sie jsx verwenden, Redakteure verwenden sie, um zwischen regulärem js und jsx zu unterscheiden und ... im Ernst, ist es so eine große Sache, es hinzuzufügen? Wenn ich den Code gut genug verstanden hätte, würde ich es einfach selbst machen, aber...

BITTE

Nur noch etwas mehr Unterstützung für die Idee, dass von .jsx vernünftigerweise erwartet werden kann, dass sie "out of the box" funktionieren. Die Problemumgehung ist trivial, sobald jemand herausfindet, was das Problem ist (und dieses Problem findet), aber meiner Erfahrung nach ist es eine _weit verbreitete Konvention_ (hier absichtlich "empfohlene" Formulierungen umgangen), um die .jsx Erweiterung zu verwenden für Dateien, die hauptsächlich eine React-Komponente exportieren.

Ich bin dabei, einfach Erweiterungen zu tauschen und meinen Weg fortzusetzen, aber ich habe Mühe zu verstehen, warum es Widerstand gibt. Noch wichtiger ist, dass dies eine vernünftige Bitte ist, für viele Entwickler ist es das erwartete Verhalten und erhöht (geringfügig) die Eintrittsbarriere. Und obwohl ich dies zunächst nicht in eine Debatte über die Vorzüge von .jsx als Erweiterung auslagern möchte, genügt es zu sagen, dass es nicht völlig unvernünftig ist, nur gültiges JavaScript in .js Dateien, und ich würde argumentieren, dass dies eine Meinung ist, die von vielen bestehenden und potenziellen next.js-Benutzern vertreten wird.

Übrigens, ich fange gerade erst an, aber liebe Dinge bisher. Danke für die ganze tolle Arbeit!

Das ist wahrscheinlich verlinkt, ich konnte keine .md Erweiterung verwenden. Ich musste den folgenden Trick anwenden, damit es auf dem Server funktioniert ( .md.js ):

next.config.js

// ...
          {
            test: /\.md\.js$/,
            loader: 'raw-loader',
          },
// ...

Ich verwende eslint mit airbnb und habe eine weitere Regel hinzugefügt, um die Warnung stumm zu schalten

{
    "extends": "airbnb",
    "rules": {
        "react/jsx-filename-extension": [1, { "extensions": [".js", ".jsx"] }]
    }
}

Hat jemand ein funktionierendes Beispiel, in dem .jsx Dateien sind?

• im Verzeichnis pages ,
• mit serverseitigem Rendering arbeiten und
• als Module aus einem anderen Verzeichnis importiert werden

?

Dies wäre eine großartige Ergänzung zum Verzeichnis /examples .

+1 für das Hinzufügen von jsx-Unterstützung.

Ich habe es behoben, indem ich etwas Ähnliches getan habe, wie @rossipedia vorgeschlagen hat .

Falls noch nicht vorhanden, erstellen Sie next.config.js im Stammverzeichnis des Projekts.
Dann einfach 'jsx' in das Array config.resolve.extensions schieben, es funktioniert einwandfrei.

module.exports = {
  webpack: function (config, { isServer }) {
    config.resolve.extensions.push('.jsx');
    return config
  }
}

BEARBEITEN
Seien Sie vorsichtig, diese Änderung scheint einen schlechten Einfluss auf die Leistung zu haben. Werde weiter recherchieren.

Wenn Sie next v5 verwenden, müssen Sie nichts ändern, die Erweiterung .jsx wird standardmäßig unterstützt. Wenn Sie etwas leistungsbezogenes sehen, versuchen Sie, auf next@canary zu aktualisieren

Das ist mir aufgefallen, super!