이와 같은 작업을 수행하려는 경우 next.config.ts를 next.config.js로 컴파일하는 것은 자신의 책임입니다. next.config.js를 변환할 계획이 없습니다.

@virzak 예, 많은 노력 없이는 아닙니다. ts-node 런타임 변환이 필요하며 Next.js에 불필요한 복잡성이 추가됩니다.

그러나 // @ts-check 를 사용하여 Flowtype에서와 마찬가지로 next.config.js $를 입력하여 확인할 수 있습니다.

nextJs Core가 typescript로 실행되고 있기 때문에 여기에 어떤 변경 사항이 있습니까?

이 문제가 재고될 가능성이 있습니까? 1년 전에 문을 닫았고 그 이후로 많은 것이 바뀌었습니다. TS 지원은 이제 핵심의 일부입니다.

내가 next.config.ts 을 갖고 싶은 구체적인 이유는 publicRuntimeConfig: { appInfo: generateAppInfo() } 를 설정하고 싶기 때문입니다. generateAppInfo() 함수는 helpers.ts 에 있으며 AppInfo 인터페이스에 대해 유형이 검사된 데이터 구조를 반환합니다. 콘텐츠에는 활성화된 기능 스위치, git commit hash, sentry id 및 실행된 앱 인스턴스에 필요한 기타 사항이 포함됩니다.

동일한 generateAppInfo() 함수가 Jest 모의에서 사용되므로 구현을 ts 파일에서 next.config.js 로 바로 옮기는 것은 불가능합니다. 이제 generateAppInfo() 를 별도의 js 파일로 추출해야 하므로 AppInfo 인터페이스에 대한 유형 검사가 손실되는 것 같습니다. 🤔

여전히 https://github.com/zeit/next.js/issues/5318#issuecomment -425398180과 동일합니다.

컴파일하면 부팅 속도가 느려지고 이점에 비해 구성 로드가 훨씬 더 복잡해집니다.

주요 성능 문제는 생산과 관련이 있다고 생각합니다. next.config.ts 가 다른 코드와 함께 .next 디렉토리로 컴파일되어 프로덕션에서 babel 또는 ts-node 를 통해 전달할 필요가 없다면 어떻게 될까요? 빌드 시간 최적화의 범위가 있다는 점을 감안할 때 부팅 시간은 약간 더 낫지 않더라도 동일하게 유지되어야 합니다.

개발이자 생산입니다. 이 파일은 구성 파일이며 일반적으로 복잡한 내용이 없어야 합니다.

부팅 성능을 저하시키지 않도록 다른 모든 것과 마찬가지로 구성을 빌드하고 캐시해야 합니다. 또한 이점에 비해 부팅 시 성능에 상당한 영향을 미친다면 충격을 받을 것입니다. 내 전체 프로젝트에서 일관된 언어를 사용하고 동일한 린트 도구 또는 esnext 구문을 포함할 수 없다는 것이 답답합니다.

이 파일은 구성 파일이며 일반적으로 복잡한 내용이 없어야 합니다.

음, 아주 간단한 사용 사례를 위한 것일까요? 모르겠어요. 저는 많은 사용자 지정 및 조정이 필요한 크고 복잡한 앱에서 작업합니다. 이에 대한 데이터는 흥미로울 것입니다. 그들은 확실히 preact.config.js 를 트랜스파일할 가치가 있다고 느꼈고 나는 그것에 대해 눈에 띄는 성능 문제를 보지 못했습니다. 이것이 왜 다른지 확실하지 않습니다.

TS를 변환하지 않고 많은 이점을 잃는 이와 같이 구성을 명령적으로 수정하는 데 특히 유용한 도구 중 하나는 Ramda 입니다. 커링할 때 동적 유형 추론에 대한 멋진 TS 지원이 있기 때문에 이것이 모든 것에 대한 나의 FP 도구 벨트입니다.

트랜스파일된 next.config.ts 지원은 여전히 ​​고려되지 않습니까? 우리의 구체적인 사용 사례는 단순히 완전한 유형의 서비스 디렉토리가 여러 기능이라는 것입니다. 서비스는 API를 사용하며 완전한 유형입니다. 현재 우리는 API를 사용하고 exportPathMap을 생성하는 데 필요하기 때문에 하나는 유형이 지정되고 하나는 유형이 지정되지 않은 서비스를 복제해야 합니다.

내보낼 URL 목록을 생성하는 것은 #9524의 getStaticPaths 로 다룹니다.

nextjs와 함께 typescript를 사용하는 경우 다음 2개의 패키지가 이미 설치되어 있을 것입니다.
@babel/core
@babel/preset-typescript

그런 다음 아래와 같은 함수를 사용하여 즉석에서 typescript 파일을 요구할 수 있습니다.

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)
}

그런 다음 next.config.js 에서 다음과 같이 사용합니다.

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

_참고: ts 파일이 next.config.js 의 동일한 폴더에 없고 필요한 ts 파일 내부에 상대 가져오기가 있는 경우 일부 경로 정보를 삽입해야 합니다. 따라서 대상 ts 파일을 단순하게 유지하십시오._

https://github.com/zeit/next.js/issues/5318#issuecomment -575959060에 대한 참고 사항

• next start 를 사용할 때 부팅 속도가 느려집니다.
• 개발 중 부팅 속도 저하

그러나 프로젝트에서 typescript를 사용하기로 결정했다면 이미 형식 안전성을 위해 성능을 어느 정도 희생하지 않았습니까? 파일이 변경될 때마다 성능에 미치는 영향이 문제가 되지 않는 것처럼 보이지만 부팅할 때 갑자기 너무 커서 극복할 수 없는 이유는 무엇입니까? 그리고 조금 똑똑하게 캐시하면 부팅할 때마다 발생하지도 않습니다.

사람들이 타이프스크립트 대신 느린 부팅에 대해 next.js 를 비난할 것이라는 우려가 있는 경우 다음과 같이 로그를 추가할 수 있습니다.

> compiled next.config.ts (1700ms)

그것은 사람들에게 어떤 도구가 그들에게 어떤 영향을 미치는지 분명히 할 것입니다.

@Janpot 은 이 방법이 아니라 Next.js 내부에 캐시되기 때문입니다. 게다가 next start 를 사용하면 next.config.js를 로드할 때 프로덕션 부팅에 영향을 줍니다. Next.js는 프로덕션 부팅 시 typescript를 컴파일하지 않습니다.

예, 동의합니다. 이 방법에는 동의하지 않습니다. 그러나 다음에 이 기능을 가상으로 구현한다면 캐시를 추가하는 것이 그리 어렵지 않을 것이라고 생각합니다. next.js에는 이미 typescript를 컴파일하고 캐시할 수 있는 인프라가 있기 때문입니다. 그리고 프로덕션 부팅의 경우 next build 실행할 때 미리 컴파일할 수 있습니까? 이 모든 것이 성능에 미치는 영향을 최소화합니다.

나는 nextjs에서 지원하기 때문에 typescript를 사용했고 next.config.js가 next.config.ts가 되는 것이 멋질 수 있다고 생각했습니다. 그러나 유형 검사를 제외하고는 config가 typescript 파일이 될 필요가 없었기 때문에 이 문제는 그다지 신경쓰이지 않았습니다. 하지만 이제 여러 곳에서 사용되는 내 next.config.js에서 ts 도우미 스크립트를 가져오고 싶었습니다. .?). 그래서 이제 나는 next.config.js가 실제로 next.config.ts여야 한다는 점에 대해 다시 걱정하고 있습니다. 그래서 ts 가져오기도 지원되므로 여기에 왔습니다...

@lsm 이 제안한 해결 방법을 여기 에서 볼 수 있지만 이 하나의 파일에 대해서만 babel 등을 사용하여 압도적인 사용자 지정이 필요합니다.

babel 또는 별도의 tsconfig와 tsc를 실행하는 일부 스크립트에서 js를 내보내므로 이 도우미 파일을 js로 가져올 수 있습니다. 어느게 더 좋지...

그러나 저자가 "이 파일 하나만"에 대한 지원도 추가하고 싶지 않다는 것을 알았습니다. 그리고 저는 약간의 아이러니를 보기 시작했습니다.

🤔🤔🤔🤔🤔🤦‍♂️

_{추신: 아직 이 모든 것을 어떻게 할지는 모르겠지만, 적어도 내 감정을 공유하고 싶었습니다.PPS getStaticPaths 를 보았지만 exportPathMap 와 같지 않습니다. 경로 매핑이 필요합니다.}

UPD. @babel/core 및 @babel/preset-typescript 는 이미 nextjs의 일부이므로 @lsm 이 제안한 코드를 시도했지만 SyntaxError: Cannot use import statement outside a module 가 표시됩니다.

UPD2. 좋아, 포기했습니다. 이 ts 도우미 스크립트를 js로 변경하고 필요한 위치에 가져왔습니다(next.config.js 및 페이지에서 fs lib를 사용하기 때문에 getStaticProps에서 사용했습니다). )

@JerryGreen 유용한 도우미를 TS로 JS로 게시하는 npm 패키지로 옮기는 것이 옵션이었습니까?

@JerryGreen과 같은 문제가 있습니다. 코드를 npm 패키지로 만드는 것을 고려하고 있었지만 프로젝트에 따라 너무 많아 각 프로젝트에 대해 새 패키지를 게시해야 합니다. 지금은 이것을 포기하고 js에서 이 코드의 일부를 복제해야 합니다.

그러나 내 사용 사례에 대한 더 나은 솔루션은 Gatsby가 gatsby-node.ts 에서 수행하는 방식과 유사하게 빌드 주기 동안 스크립트를 실행하는 옵션을 갖는 것입니다.

@dpwolfe 예, @beppek 에 동의합니다. 이것은 너무 프로젝트에 국한된 것 같습니다. 제 경우에는 20200917-hello-world 와 같은 날짜(짧은 타임스탬프)로 시작하는 파일이 페이지 폴더에 있고 /hello-world 경로를 통해 액세스할 수 있기를 원합니다. 그래서 파일 시스템을 통과하고 정규 표현식을 적용하고 exportPathMap 에 필요한 경로를 생성하는 함수를 작성해야 했습니다 /blog/posts/20200917-hello-world , -> /hello-world . 너무 프로젝트 특정적인 것 같아서 패키지에 게시해야 하는 실제 이유가 없습니다. Btw 나는 getStaticProps 에 대해 약간 거짓말을 했습니다. 나는 그것이 필요하지 않다는 것이 밝혀졌습니다. 사용자 정의 exportPathMap 이면 충분합니다. 그래도 이 도우미가 js로 작성되어야 한다는 것이 이상합니다. ts로 작성하면 next.config.js 에서 가져올 수 없기 때문입니다. 아마도 이 도우미를 js로 옮겨야 할 것입니다. 패키지를 분리하여 ts로 작성하고 js로 컴파일하면 next.config.js 내에서 사용할 수 있지만 개인적인 필요에 따라 거의 누구에게나 필요할 것입니다.

이와 같이 억제해야 하는 eslint 오류가 발생했습니다.

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

이것은 다시 열거나 적어도 이것이 알려진 문제임을 언급하기 위해 typescript 문서에 추가되어야 합니다. 이를 미리 문서화하거나 next.config.ts를 더 잘 허용하기 위해 세련미를 추가할 것입니다.