Wenn Sie so etwas tun möchten, liegt es in Ihrer eigenen Verantwortung, next.config.ts in next.config.js zu kompilieren. Wir planen nicht, next.config.js zu transpilieren.

@virzak Ja, nicht ohne viel Aufwand. Es erfordert Laufzeittranspilation mit ts-node und fügt Next.js unnötige Komplexität hinzu.

Sie können jedoch // @ts-check verwenden, um Ihre next.config.js $ zu überprüfen, genau wie Sie es in Flowtype tun würden.

Gibt es hier Änderungen, da nextJs Core mit Typoskript ausgeführt wird?

Besteht die Möglichkeit, dass dieses Thema noch einmal überdacht wird? Es wurde vor über einem Jahr geschlossen und seitdem hat sich viel geändert, der TS-Support ist jetzt Teil des Kerns.

Ein bestimmter Grund, warum ich next.config.ts haben möchte, ist, dass ich publicRuntimeConfig: { appInfo: generateAppInfo() } setzen möchte. Die Funktion generateAppInfo() befindet sich in helpers.ts und gibt eine Datenstruktur zurück, die gegen die Schnittstelle AppInfo typgeprüft ist. Der Inhalt umfasst aktivierte Funktionsschalter, Git-Commit-Hash, Sentry-ID und andere Dinge, die eine gestartete App-Instanz benötigen würde.

Dieselbe generateAppInfo() -Funktion wird in Jest-Mocks verwendet, daher wäre es nicht möglich, ihre Implementierung aus einer ts-Datei direkt in next.config.js zu verschieben. Scheint, als müsste ich jetzt generateAppInfo() in eine separate js -Datei extrahieren, wodurch die Typprüfung gegenüber der AppInfo -Schnittstelle 🤔 verloren geht

Immer noch dasselbe wie https://github.com/zeit/next.js/issues/5318#issuecomment -425398180

Das Kompilieren würde den Bootvorgang verlangsamen und das Laden der Konfiguration im Vergleich zu den Vorteilen erheblich komplexer machen.

Ich glaube, das Hauptleistungsproblem ist produktionsbedingt. Was wäre, wenn next.config.ts zusammen mit anderem Code in das Verzeichnis .next kompiliert würde, wodurch die Notwendigkeit entfällt, es über babel oder ts-node in der Produktion zu übergeben? Die Startzeit sollte gleich bleiben, wenn nicht sogar etwas besser, da Spielraum für Build-Time-Optimierungen vorhanden ist.

Es ist sowohl Entwicklung als auch Produktion. Beachten Sie, dass diese Datei eine Konfigurationsdatei ist und im Allgemeinen nichts Komplexes enthalten sollte.

Es sollte die Konfiguration wie alles andere nur erstellen und zwischenspeichern, damit die Startleistung nicht beeinträchtigt wird. Außerdem wäre ich schockiert, wenn es im Vergleich zu den Vorteilen einen erheblichen Einfluss auf die Leistung beim Booten hätte. Es ist frustrierend, dass ich nicht in der Lage bin, während meines gesamten Projekts eine konsistente Sprache zu verwenden und dieselben Linting-Tools oder esnext-Syntax einzubeziehen.

Beachten Sie, dass diese Datei eine Konfigurationsdatei ist und im Allgemeinen nichts Komplexes enthalten sollte.

Ähm, vielleicht für supereinfache Anwendungsfälle? Ich weiß nicht. Ich arbeite an großen, komplexen Apps, die viele Anpassungen und Optimierungen erfordern. Daten dazu wären interessant. Sie hielten es auf jeden Fall für lohnend, preact.config.js zu transpilieren, und ich habe keine merklichen Leistungsprobleme damit gesehen. Nicht sicher, warum dies anders sein sollte.

Ein besonders nützliches Werkzeug zum zwingenden Ändern von Konfigurationen wie diesem, das viele Vorteile verliert, ohne TS zu transpilieren, ist Ramda . Das ist mein FP-Toolbelt für alles, weil es eine großartige TS-Unterstützung für dynamische Typinferenz beim Curry bietet.

Wird die Unterstützung eines transpilierten next.config.ts immer noch nicht in Betracht gezogen? Unser spezifischer Anwendungsfall ist einfach, dass wir mehrere Funktionen eines Dienstverzeichnisses haben, die vollständig typisiert sind. Die Dienste verbrauchen unsere APIs und sind vollständig typisiert. Derzeit müssen wir den Dienst duplizieren, einen typisierten und einen nicht typisierten, da wir sie auch benötigen, um unsere APIs zu nutzen und unsere exportPathMap zu generieren.

Das Generieren einer Liste mit zu exportierenden URLs wird von getStaticPaths in #9524 behandelt

Sie haben wahrscheinlich bereits die folgenden 2 Pakete installiert, wenn Sie Typoskript mit nextjs verwenden:
@babel/core
@babel/preset-typescript

Dann können Sie eine Funktion wie die folgende verwenden, um eine Typoskript-Datei im Handumdrehen anzufordern:

function requireTypescript(path) {
  const fileContent = require('fs').readFileSync(path, 'utf8')
  const compiled = require('@babel/core').transform(
    fileContent,
    {
      filename: path,
      presets: [ '@babel/preset-typescript' ],
    },
  )
  return eval(compiled.code)
}

Verwenden Sie es dann in Ihrem next.config.js wie folgt:

const myModule = requireTypescript('./path/to/mymodule.ts')

_Hinweis: Sie müssen einige Pfadinformationen einfügen, wenn sich Ihre ts-Datei nicht im selben Ordner wie next.config.js befindet und Sie einen relativen Import in der benötigten ts-Datei haben. Halten Sie also die Ziel-ts-Datei einfach._

Hinweis zu https://github.com/zeit/next.js/issues/5318#issuecomment -575959060

• Verlangsamt den Systemstart bei Verwendung next start
• Verlangsamt den Systemstart in der Entwicklung

Aber wenn Sie sich entschieden haben, Typoskript in Ihrem Projekt zu verwenden, haben Sie dann nicht bereits etwas Leistung gegen Typsicherheit eingetauscht? Wie kommt es, dass die Auswirkungen auf die Leistung nicht als problematisch angesehen werden, wenn sie bei jeder Änderung einer Datei auftreten, aber plötzlich so unüberwindbar sind, wenn sie einmal beim Booten sind? Und wenn Sie es ein bisschen schlau zwischenspeichern, passiert es nicht einmal bei jedem Start.

Wenn die Sorge besteht, dass die Leute next.js für einen langsamen Start verantwortlich machen würden, anstatt für Typoskript, könnte vielleicht ein Protokoll wie hinzugefügt werden

> compiled next.config.ts (1700ms)

Das würde den Menschen verdeutlichen, welche Auswirkungen der Einsatz welchen Tools für sie hat.

@Janpot , weil es in Next.js zwischengespeichert wird und nicht mit dieser Methode. Darüber hinaus wirkt es sich auf den Produktionsstart aus, wenn Sie next start verwenden, da es next.config.js lädt. Next.js kompiliert kein Typoskript beim Produktionsstart.

Ja, ich stimme zu, nicht mit dieser Methode. Aber wenn diese Funktion als nächstes hypothetisch implementiert würde, wäre es vermutlich nicht allzu schwer, den Cache hinzuzufügen. Da next.js bereits über eine Infrastruktur zum Kompilieren und Zwischenspeichern von Typoskript verfügt. Und für den Produktionsstart könnte es beim Ausführen next build vorkompiliert werden? All dies würde die Auswirkungen auf die Leistung sehr gering machen.

Ich habe Typoskript verwendet, seit es in nextjs unterstützt wird, und dachte, dass es cool sein könnte, dass next.config.js next.config.ts ist. Aber abgesehen von der Typprüfung brauchte ich nie, dass die Konfiguration eine Typoskript-Datei ist, also störte mich dieses Problem nicht allzu sehr. Aber jetzt wollte ich ein ts Hilfsskript in meine next.config.js importieren (um Pfade für exportPathMap zu generieren), das an mehreren Stellen verwendet wird, aber es stellt sich heraus, dass ich ts hier nicht verwenden kann (offensichtlich. .?). Jetzt mache ich mir also wieder Sorgen, dass next.config.js eigentlich next.config.ts sein sollte, also werden ts-Importe auch unterstützt, also bin ich hierher gekommen ...

Ich sehe die von @lsm hier vorgeschlagene Problemumgehung, aber dies erfordert eine überwältigende Anpassung mit babel usw. nur für diese eine Datei.

Entweder babel oder eine separate tsconfig und ein Skript, das tsc ausführt, um js auszugeben, sodass ich diese Hilfsdatei als js importieren könnte. Was nicht besser ist...

Aber dann sehe ich, dass der Autor auch keine Unterstützung für "nur diese eine Datei" hinzufügen möchte, und ich fange an, etwas Ironie zu sehen.

🤔🤔🤔🤔🤔🤦‍♂️

_{PS Ich weiß noch nicht, was ich mit all dem mache, aber ich wollte zumindest meine Gefühle teilenPPS Ich habe getStaticPaths gesehen, aber es ist nicht dasselbe wie exportPathMap , ich brauche eine Pfadzuordnung}

UPD. Auf den zweiten Blick sind @babel/core und @babel/preset-typescript bereits Teil von nextjs, also habe ich den von @lsm vorgeschlagenen Code ausprobiert, aber ich bekomme SyntaxError: Cannot use import statement outside a module

UPD2. ok, ich habe aufgegeben: Ich habe dieses ts-Hilfsskript in js geändert und es dort benötigt/importiert, wo ich es brauchte (in next.config.js und auf einer Seite, habe es in getStaticProps verwendet, da es fs lib verwendet )

@JerryGreen Wäre es eine Option für Sie gewesen, diesen nützlichen Helfer als TS in ein npm-Paket zu verschieben, das als JS veröffentlicht wird?

Ich habe das gleiche Problem wie @JerryGreen. Ich habe überlegt, den Code zu einem npm-Paket zu machen, aber es gibt zu viel, das projektspezifisch ist, also müsste ich für jedes Projekt ein neues Paket veröffentlichen. Ich muss das jetzt aufgeben und nur einen Teil dieses Codes in js duplizieren.

Eine bessere Lösung für meinen Anwendungsfall wäre jedoch die Möglichkeit, Skripte während des Build-Zyklus auszuführen, ähnlich wie es Gatsby in gatsby-node.ts tut.

@dpwolfe ja, ich stimme @beppek zu, diese Sache scheint ein bisschen zu projektspezifisch zu sein. In meinem Fall habe ich Dateien im Seitenordner, die mit einem Datum beginnen (Zeitstempel verkürzen), etwa 20200917-hello-world , und ich möchte, dass sie über den Pfad /hello-world zugänglich sind. Also musste ich eine Funktion schreiben, die das Dateisystem durchläuft, reguläre Ausdrücke anwendet und erforderliche Pfade für exportPathMap generiert und ein Objekt erstellt, das aus Einträgen wie /blog/posts/20200917-hello-world , -> /hello-world besteht . Scheint zu projektspezifisch zu sein, daher sehe ich keine tatsächlichen Gründe, es in einem Paket zu veröffentlichen. Übrigens habe ich etwas über getStaticProps gelogen - es stellte sich heraus, dass ich das nicht brauche. Benutzerdefinierte exportPathMap reichen für diesen Bedarf aus. Trotzdem seltsam, dass dieser Helfer in js geschrieben werden musste, denn wenn ich ihn in ts schreibe, könnte ich ihn nicht aus next.config.js importieren ... Ich sollte diesen Helfer wahrscheinlich tatsächlich in a verschieben separates Paket, schreiben Sie es in ts, aber kompilieren Sie es in js, so dass es möglich sein wird, es innerhalb next.config.js zu verwenden, aber nur für den persönlichen Bedarf, kaum jemand würde das brauchen.

Ich stoße auf Eslint-Fehler, die so unterdrückt werden müssen

/* eslint-disable @typescript-eslint/no-var-requires */
const withFonts = require('next-fonts');

Dies sollte erneut geöffnet oder zumindest etwas zur Typoskript-Dokumentation hinzugefügt werden, um zu erwähnen, dass dies ein bekanntes Problem ist. Es würde Glanz verleihen, dies im Voraus zu dokumentieren oder noch besser next.config.ts zuzulassen.