Deno v2를 향하여 - Deno v2, deno_std v1, Fresh v2에 대하여

• Deno v2를 향하여 - Deno v2, deno_std v1, Fresh v2에 대하여
  • Deno v2에 대하여
    • Node.js 호환성 개선
      • Node.js 호환성에 힘을 쏟는 배경
      • Node.js 호환성의 현 상황
    • Deno v2를 위한 Node.js 호환성 대응
      • BYONM의 기본 활성화
      • deno install 명령어의 동작 변경
      • npm 및 Yarn 등과의 상호 운용성 개선
    • Node.js 호환성에 관한 요약
  • JSR
    • Deno에서 JSR 패키지 사용 방법
      • jsr: URL
      • deno add 명령어
    • 패키지 공개 (deno publish)
    • Fast Check
    • JSR 도입 배경
  • 워크스페이스 기능 도입
  • 비추천 API의 삭제
  • 비추천 API의 안정화
  • DENO_FUTURE 환경 변수 도입
  • deno_std v1
    • deno_std v1은 언제 나오나요?
    • v1이 쉽게 릴리스되지 못한 배경
    • JSR로의 이동
    • deno.land/std는 어떻게 되나요?
  • Fresh v2
    • Fresh v2의 개발 상황
    • 주요 변경 사항
      • JSR로의 공개
      • Express와 유사한 API 제공
      • createDefine() API
      • @fresh/core/compat
    • 프로젝트 구성에 관한 변경
    • 마이그레이션 가이드
  • 맺음말

 

Deno v1이 출시된 지 벌써 4년이 흘렀습니다.

 

슬슬 Deno v2는 언제쯤 나올까 궁금해하시는 분들도 있을지 모르겠습니다.

 

이 글에서는 Deno v2와 그 주변 환경에 대해 현재 어떤 준비가 진행되고 있는지 정리해 보겠습니다.

Deno v2에 대하여

Deno v2의 릴리스 시기에 대해서는 아직 정확히 알 수 없는 상황입니다.

 

하지만, 현재 Deno v2의 릴리스를 준비하는 작업이 조금씩 진행되고 있는 것을 볼 수 있습니다.

 

구체적으로 어떤 변경 사항이 계획되거나 진행 중인지 살펴보겠습니다.

 

Node.js 호환성 개선

 

이전에 몇몇 기사에서도 다뤘듯이, Node.js 호환성 개선은 계속해서 상당한 노력을 기울여 진행되고 있습니다.

 

현재까지 다음과 같은 기능들이 구현되었습니다.

• npm: URL을 통한 npm 패키지의 import
• node_modules 디렉토리 생성
• package.json 지원
• BYONM
• .npmrc 지원 (Deno v1.44)

Node.js 호환성에 힘을 쏟는 배경

 

배경 중 하나는 의존 관계의 중복 문제를 해결하려는 목적이 있습니다.

 

Deno의 큰 특징 중 하나는 임의의 URL에서 모듈을 import할 수 있다는 점입니다.

 

이를 활용하기 위해 Deno 공식 사이트에서는 deno.land/x라는 레지스트리를 제공하고 있으며, 많은 Deno용 라이브러리가 이곳에서 공개되고 있습니다.

 

다음은 deno.land/x에서 라이브러리를 사용하는 예입니다.

import { connect } from "https://deno.land/x/redis@v0.32.3/mod.ts";
const redis = await connect({
  hostname: "127.0.0.1",
  port: 6379,
});

 

이 기능은 간단하고 이해하기 쉬워서 스크립팅 등에 특히 유용하지만, 대규모 애플리케이션에서는 의존 관계의 중복이 발생할 수 있습니다.

 

예를 들어, std/uuid/v1.ts에 의존하는 foo와 bar라는 두 패키지가 있다고 가정해 봅시다.

 

패키지 foo는 std/uuid/v1.ts의 0.223.0 버전에, 패키지 bar는 0.224.0 버전에 의존한다고 가정합니다.

app
├── foo
│   └── std@0.223.0/uuid/v1.ts
└── bar
    └── std@0.224.0/uuid/v1.ts

 

패키지 foo와 bar가 각각 의존하는 std/uuid/v1.ts의 0.223.0과 0.224.0은 내용이 전혀 다르지 않습니다.

 

하지만 버전이 다르기 때문에, 애플리케이션이 foo와 bar의 두 패키지에 모두 의존할 경우, 중복된 모듈(std/uuid/v1.ts의 0.223.0과 0.224.0)이 여러 번 설치되는 문제가 발생합니다.

 

이 문제를 해결하기 위해서는 semver에 기반한 의존 해결 메커니즘이 필요합니다.

 

Deno에서 npm 패키지를 지원하기 위해서는 semver에 기반한 의존 해결 메커니즘이 필요하기 때문에, Deno에 npm 패키지 지원이 도입되면 자연스럽게 이 문제에 대한 해결책이 제공됩니다.

 

또한, npm 패키지 지원으로 인해 Node.js용 풍부한 자산을 Deno에서도 활용할 수 있는 기회가 생깁니다.

Node.js 호환성의 현 상황

Node.js 호환성 개선을 통해 Docusaurus가 Deno에서 동작하도록 되었습니다.

 

이에 따라, Deno 공식 문서 사이트도 Node.js+Docusaurus에서 Deno+Docusaurus로 이전되었습니다.

 

또한, Next.js가 동작하도록 되어 최근 Deno v1.44의 공식 블로그에서 발표되었습니다.

 

(이와 관련하여 후속 블로그가 Deno 공식 사이트에 게시될 예정입니다.)

 

다만, Next.js를 동작시키기 위해서는 현재 DENO_FUTURE=1 플래그를 지정해야 하는 것 같습니다.

 

Deno v2를 위한 Node.js 호환성 대응

 

Deno v2를 위해 다음과 같은 변경 사항이 검토되고 있습니다.

• BYONM의 기본 활성화
• deno install 명령어의 동작 변경
• npm 및 Yarn 등과의 상호 운용성 개선

각 항목에 대해 소개하겠습니다.

 

BYONM의 기본 활성화

 

BYONM은 npm, pnpm, Yarn 등 패키지 매니저가 생성한 node_modules 디렉토리에서 npm 패키지를 읽어들이는 기능입니다.

 

이 기능을 사용하면 npm 패키지 관리는 Yarn에 맡기고, Deno에서는 Yarn으로 설치된 패키지를 그대로 사용할 수 있습니다.

 

현재는 deno.json 등에서 명시적으로 활성화해야 BYONM을 사용할 수 있습니다.

 

Deno v2에서는 package.json이 존재할 경우 기본적으로 BYONM을 활성화하는 것이 계획되어 있습니다.

 

후술할 DENO_FUTURE=1을 지정하면 Deno v1에서도 이 동작을 시험해 볼 수 있습니다.

 

deno install 명령어의 동작 변경

 

Deno에는 deno install이라는 명령어가 있습니다.

 

Deno v1에서 deno install 명령어는 임의의 호스트에서 공개된 스크립트를 로컬에 설치하기 위한 명령어입니다.

 

(Node.js의 npm install -g, Go의 go install에 해당하는 동작을 합니다.)

$ deno install -rf --allow-read=. --allow-write=. --allow-net https://deno.land/x/udd@0.8.2/main.ts
⚠️ `deno install` behavior will change in Deno 2. To preserve the current behavior use the `-g` or `--global` flag.
✅ Successfully installed udd
/path/to/.deno/bin/udd

 

Deno v2에서는 deno install 명령어의 동작이 변경될 예정입니다.

 

먼저, deno install 명령어는 의존 관계를 프로젝트에 추가하는 명령어로 동작이 변경됩니다.

 

(후술할 deno add 명령어와 동일한 동작을 합니다.)

# 현 시점에서 이 동작을 시험하려면 `DENO_FUTURE=1`을 지정해야 합니다.
$ deno install npm:chalk@5.3.0

# deno.json에 chalk에 관한 매핑이 기록됩니다.
$ cat deno.json | jq .imports.chalk
"npm:chalk@^5.3.0"

 

또한, 인수 없이 deno install 명령어를 실행하면 프로젝트가 의존하는 각 패키지를 다운로드하여 로컬에 캐시합니다.

# 현 시점에서 이 동작을 시험하려면 `DENO_FUTURE=1`을 지정해야 합니다.
$ deno install

 

이와 같이, deno install 명령어는 npm install이나 yarn add와 유사한 동작을 하도록 변경될 예정입니다.

 

만약 deno install 명령어가 Deno v1과 동일한 동작을 하도록 하려면, 명시적으로 --global 옵션을 지정해야 합니다.

$ deno install --global -rf --allow-read=. --allow-write=. --allow-net https://deno.land/x/udd@0.8.2/main.ts

 

npm 및 Yarn 등과의 상호 운용성 개선

 

Deno는 자체적으로 락 파일(deno.lock) 메커니즘을 갖추고 있습니다.

 

최근 릴리스된 Deno v1.44에서는 package.json이 존재할 경우 자동으로 락 파일을 생성하는 기능도 도입되었습니다.

 

하지만, 기존 Node.js 애플리케이션에서 Deno를 사용하는 경우, deno.lock이 아닌 Yarn 등에서 생성한 락 파일을 그대로 사용하고 싶을 때가 있을 것입니다.

 

이러한 요구를 충족시키기 위해, 앞서 언급한 deno install 명령어에서 npm이나 Yarn 등이 생성한 락 파일을 인식할 수 있도록 하는 것이 Deno v2에서 검토되고 있습니다.

 

Node.js 호환성에 관한 요약

 

Deno v2를 위해서는 주로 기존 패키지 매니저와의 상호 운용성 개선 및 사용감의 통일 등이 예상됩니다.

 

아마도 기존 Node.js 프로젝트에서 소스 코드를 변경하지 않고 Deno를 사용할 수 있도록 하는 것이 목표일 것입니다.

 

앞으로 Deno 공식 사이트에서 Next.js 사용에 대한 기사가 게시될 예정이므로, 그 기사에서도 여러 가지 발표가 있을 가능성이 있습니다.

JSR

JSR이라는 패키지 레지스트리가 Deno 공식 사이트에 공개되었습니다.

 

이 JSR의 특징으로는 TypeScript의 네이티브 지원 및 문서 자동 생성 기능 등이 있습니다.

 

또한, npm 레지스트리와 호환되며, 다음과 같은 도구를 이용해 Node.js나 Bun 등의 런타임에서도 JSR에서 공개된 패키지를 사용할 수 있습니다.

 

이 JSR의 공개와 함께 Deno에 JSR의 네이티브 지원이 추가되었습니다.

 

Deno에서 JSR 패키지 사용 방법

 

jsr: URL

Deno에서 JSR로 공개된 패키지를 사용하려면 jsr:@<scope>/<package>@<version> 형식의 URL을 지정합니다.

 

예를 들어, 다음은 @david라는 스코프로 공개된 dax 패키지의 v0.41.0을 사용하는 예입니다.

import $ from "jsr:@david/dax@0.41.0";

$.log("Hello Deno!");

 

이와 같이 JSR에서는 패키지를 공개할 때 반드시 스코프를 지정해야 합니다.

jsr:를 통해 지정된 JSR 패키지는 일반적인 https: 형식의 패키지와 마찬가지로, Deno를 실행할 때 자동으로 다운로드되어 캐시됩니다.

 

deno add 명령어

 

또한, deno add라는 명령어도 추가되었습니다.

 

이 명령어를 사용하면 Deno가 지정된 JSR 패키지를 deno.json의 imports에 작성해줍니다.

$ deno add @david/dax
Add @david/dax - jsr:@david/dax@^0.41.0

$ cat deno.json | jq '.imports."@david/dax"' 
"jsr:@david/dax@^0.41.0"

 

이를 통해 다음과 같이 @david/dax 패키지를 불러올 수 있습니다.

import $ from "@david/dax";

$.log("Hello Deno!");

 

또한, npm 패키지도 추가할 수 있습니다.

$ deno add npm:chalk@^5 
Add chalk - npm:chalk@^5.3.0

$ cat deno.json | jq .imports.chalk
"npm:chalk@^5.3.0"

 

패키지 공개 (deno publish)

 

Deno 본체에서 JSR에 패키지를 공개하기 위해 deno publish라는 명령어가 제공됩니다.

 

이 deno publish는 드라이 런도 지원하므로, 패키지를 공개하기 전에 이를 시험해볼 수 있습니다.

$ deno publish --dry-run

 

패키지 공개에 관한 자세한 내용은 다음 페이지를 참조하세요.

 

Fast Check

 

JSR에 관련된 독자적인 기능으로 fast check가 Deno에 포함되어 있습니다.

fast check는 TypeScript에서 타입 체크를 느리게 할 수 있는 정의를 감지하는 기능입니다.

 

구체적으로는, 패키지의 공개 API 중 명시적으로 타입 정의가 되어 있지 않은 함수 등을 감지합니다.

// Bad - 반환 타입 정의가 생략됨
export function add(a: number, b: number) {
  return a + b;
}

// Good - 매개변수와 반환 타입이 제대로 정의됨
export function add(a: number, b: number): number {
  return a + b;
}

 

이 slow types가 있는 패키지는 그렇지 않은 패키지에 비해 타입 체크 시 시간이 더 걸릴 수 있습니다.

 

Deno는 deno publish 등의 명령어를 실행할 때 fast check를 실행하여, JSR 패키지 이용자가 slow types로 인해 경험이 저하되지 않도록 합니다.

 

이 fast check는 JSR 패키지 작성자를 위한 기능입니다.

 

따라서 사용자로서 JSR 패키지를 이용하는 데는 특별히 신경 쓰지 않아도 됩니다.

slow types에 관한 자세한 내용은 다음 문서를 참조하세요.

 

JSR 도입 배경

 

jsr: URL은 원래 deno: URL로 도입될 예정이었던 기능으로 보입니다.

 

원래 deno: URL이 도입되려 했던 배경은 앞서 언급한 의존 관계 중복 문제를 해결하기 위한 목적이었습니다.

 

npm 패키지를 Deno가 지원함으로써 의존 관계 중복 문제는 부분적으로 해결됩니다.

 

npm 패키지를 사용할 경우 Deno가 semver에 기반해 의존 해결을 해주기 때문입니다.

 

그러나, Deno나 Deno Deploy용 애플리케이션을 개발할 때는 npm 패키지가 아닌 Deno나 Deno Deploy용으로 별도로 개발된 라이브러리(예: Fresh, deno_std 등)를 사용하고 싶을 때가 있을 것입니다.

 

이 경우 deno.land/x를 이용하게 되므로, 결국 앞서 언급한 의존 관계 중복 문제가 발생합니다.

 

이를 해결하기 위해서는 Deno용 패키지에도 semver 기반의 의존 해결 메커니즘이 필요합니다.

 

이 문제의 해결책 중 하나로 Deno용 라이브러리를 npm 레지스트리에 공개하는 방법이 있을 것입니다.

 

하지만, Deno용 라이브러리를 npm 레지스트리에 공개하면 그 패키지를 Node.js 등에서도 사용하고 싶다는 요청이 발생할 수 있습니다.

 

이 경우 Node.js에서는 TypeScript 코드를 직접 실행할 수 없으므로, 패키지 공개 전에 TypeScript 코드를 JavaScript로 트랜스파일하는 등의 작업이 필요합니다.

 

JSR은 레지스트리가 이러한 작업을 대신 처리해 줌으로써 패키지 공개에 관한 부담을 줄여줍니다.

 

요약하자면, 다음과 같은 과제를 해결하기 위해 JSR이 개발된 것으로 보입니다.

• Deno용 패키지에서도 의존 관계 중복 문제를 해결하고 싶다.
• 패키지 공개에 관한 경험을 개선하고 싶다.

이 JSR에는 이미 Hono나 Oak 등의 유명 패키지도 공개되어 있으며, 앞으로 Deno용 라이브러리를 이용할 때 JSR을 이용하는 것이 주류가 될 가능성이 큽니다.

 

워크스페이스 기능 도입

 

Deno에 워크스페이스 기능이 도입됩니다.

 

워크스페이스를 이용하려면 먼저 deno.json에서 workspaces를 정의해야 합니다.

deno.json
{
  "imports": {
    "$dax": "jsr:@david/dax@0.41.0"
  },
  "workspaces": [
    "foo",
    "bar"
  ]
}

 

위 예에서는 foo와 bar라는 두 개의 워크스페이스가 정의되어 있습니다.

 

디렉토리 구조는 각 워크스페이스마다 디렉토리를 마련해야 합니다.

.
├── deno.json
├── mod.ts
├── bar
│   ├── deno.json
│   └── mod.ts
└── foo
    ├── deno.json
    └── mod.ts

 

이렇게 각 워크스페이스마다 deno.json을 배치할 수 있습니다.

 

다음은 bar 워크스페이스의 deno.json 정의로, name, version, exports 등을 정의해야 합니다.

bar/deno.json
{
  "name": "@test/bar",
  "version": "0.0.1",
  "exports": {
    ".": "./mod.ts"
  },
  "imports": {
    "chalk": "npm:chalk@5.2.0"
  }
}

 

bar 워크스페이스 내 모듈에서는 bar/deno.json과 루트 deno.json에 기반해 의존을 해결합니다.

bar/mod.ts
// `chalk@5.2.0`가 로드됩니다
export { default as chalk } from "chalk";

// 루트 디렉토리에 정의된 `@david/dax@0.41.0`가 로드됩니다
export { default as $ } from "$dax";

 

foo 워크스페이스도 마찬가지입니다.

 

여기서는 bar 워크스페이스와는 다른 버전의 chalk를 로드하고 있습니다.

foo/deno.json
{
  "name": "@test/foo",
  "version": "0.0.1",
  "exports": {
    ".": "./mod.ts"
  },
  "imports": {
    "chalk": "npm:chalk@5.3.0"
  }
}

```js
foo/mod.ts
// `chalk@5.3.0`가 로드됩니다
export { default as chalk } from "chalk";

 

다음은 프로젝트 루트 디렉토리에 배치된 mod.ts의 예로, 각 워크스페이스를 패키지로 불러올 수 있습니다.

mod.ts
// foo를 불러옵니다
import { chalk as chalk_foo } from "@test/foo";

// bar를 불러옵니다
import { chalk as chalk_bar, $ } from "@test/bar";

console.info(chalk_foo.red("foo"));
console.info(chalk_bar.red("bar"));

// foo에서는 `chalk@5.3.0`, bar에서는 `chalk@5.2.0`이 사용되므로, false가 출력됩니다
console.assert(chalk_foo.red !== chalk_bar.red);

$.log(chalk_foo.green("Hello bar"));

 

Deno에서는 프로젝트마다 하나의 Import maps만 정의할 수 있는 문제점이 있었습니다.

 

워크스페이스 기능 도입으로 이 문제를 해결할 수 있을 것으로 기대됩니다.

 

이 워크스페이스 기능은 이미 Deno 본체에 구현되어 있지만, Deno v2를 위한 몇 가지 개선 작업이 남아 있는 상태입니다.

 

구체적으로는 npm 워크스페이스 지원 등이 검토되고 있습니다. 자세한 진행 상황은 다음 이슈를 참조하세요.

 

비추천 API의 삭제

 

Deno 본체에서 비추천 API가 삭제될 예정입니다.

 

대상 API는 다음 마이그레이션 가이드에서 설명하고 있습니다.

 

주요한 변경 사항으로는 Deno.Reader와 Deno.Writer의 삭제가 예정되어 있습니다.

 

이들은 Deno 초기 단계에서 Go의 io.Reader와 io.Writer 등에 영향을 받아 도입되었습니다.

 

Deno v1 릴리스 이후, Deno에서는 Web API의 이용이 중요시되었기 때문에, IO 관련 기능도 Deno.Reader나 Deno.Writer가 아닌 Web Streams API를 기반으로 구현되는 경우가 많아졌습니다.

 

또한, 다음 이슈에서 설명된 것처럼, 현재 Deno에서는 시스템 호출에 의존하지 않는 기능에 대해서는 가능한 한 Deno.* 아래에 두지 않는 방침이 취해지고 있습니다.

 

이러한 배경으로 인해 Deno 본체에서 Deno.Reader와 Deno.Writer 등의 타입이 삭제되었습니다.

 

(참고로, Deno.Reader와 Deno.Writer는 타입만 삭제되었으며, Deno.FsFile 등의 API에서는 여전히 read나 write 등의 메서드가 제공됩니다.)

 

이 타입들은 @std/io/types로 이동되었으므로 앞으로는 여기서 사용하면 됩니다.

 

비추천 API의 안정화

 

지금까지 비추천 API로 제공되었던 몇 가지 기능이 v2에서 안정화될 가능성이 높습니다.

 

주요한 기능으로는 다음과 같은 것들이 있습니다.

• FFI (Deno.dlopen 등)
• WebGPU API

DENO_FUTURE 환경 변수 도입

DENO_FUTURE라는 환경 변수가 도입되었습니다.

 

이 환경 변수를 지정하면 Deno에서 장래에 예정된 파괴적인 변경 사항을 미리 시험해 볼 수 있습니다.

 

예를 들어, DENO_FUTURE를 사용하면 비추천 상태로 삭제 예정인 API를 무효화할 수 있습니다.

$ DENO_FUTURE=1 deno run mod.ts

 

이 환경 변수를 설정하면 v2로 빠르게 전환할 수 있을 것이므로, 패키지 등을 개발하는 경우 CI 등의 테스트 실행 시 이 환경 변수를 활성화하면 편리할 수 있습니다.

 

deno_std v1

 

Deno의 공식 표준 패키지인 deno_std v1에 대해 설명하겠습니다.

 

deno_std v1은 언제 나오나요?

 

결론부터 말하자면, deno_std에서 제공되는 모듈 중 하나인 @std/bytes는 이미 v1이 릴리스되었습니다. 구체적으로 어떤 상황인지 설명드리겠습니다.

 

v1이 쉽게 릴리스되지 못한 배경

 

deno_std에는 다양한 모듈이 존재합니다.

 

예)

• @std/path
• @std/fs
• @std/assert
• @std/expect

이 모듈들은 각기 성숙도에 차이가 있습니다.

 

예를 들어, @std/path는 사용 빈도가 높고 오랜 기간 유지보수되어 비교적 안정적으로 동작한다고 볼 수 있습니다.

 

따라서 @std/path는 앞으로도 파괴적인 변경이 일어날 가능성이 낮다고 생각됩니다.

 

반면, @std/expect 등은 아직 성숙도가 높지 않은 패키지도 있습니다.

 

따라서 deno_std 전체를 v1으로 릴리스하면 성숙도가 낮은 패키지에 대해 파괴적인 변경을 가하기가 어려워집니다.

 

JSR로의 이동

 

Deno 공식 사이트에서 JSR이라는 패키지 레지스트리가 개발되었습니다.

 

deno_std도 이 JSR로 패키지가 공개됩니다. (예: @std)

 

JSR이 등장함에 따라 deno_std의 각 모듈을 독립적으로 버전 관리할 수 있게 되었습니다.

 

이에 따라 안정성이 높다고 생각되는 @std/bytes는 최근 v1이 릴리스되었습니다.

 

@std/path와 @std/collections 등의 모듈도 이미 v1의 RC 버전이 공개되었으며, 가까운 시일 내에 v1이 릴리스될 가능성이 높습니다.

 

반면, @std/expect 등의 성숙도가 아직 높은 모듈은 당분간 v1이 릴리스되지 않고 개발이 계속될 것입니다.

 

deno.land/std는 어떻게 되나요?

 

deno.land/std에는 과거 버전의 deno_std가 계속 남아 있지만, JSR로 이동한 버전은 공개되지 않습니다.

 

따라서 앞으로는 deno.land/std가 아닌 JSR에서 deno_std를 사용하는 것이 권장됩니다.

$ deno add @std/path

 

Fresh v2

 

Fresh는 Preact와 esbuild를 기반으로 한 Deno 공식 웹 프레임워크입니다.

 

Fresh v2의 개발 상황

 

원래 Fresh v2를 위한 코드는 독립된 브랜치에서 개발되었지만, 지난달에 메인 브랜치에 병합되었습니다.

 

현재 Fresh v2의 알파 버전이 JSR에서 공개되어 있으며, 가까운 시일 내에 Fresh v2가 릴리스될 가능성이 있습니다.

 

Fresh v2의 로드맵은 다음 페이지에서 공개되어 있습니다.

 

또한 Fresh 리포지토리의 www 디렉토리 코드를 보면 이해가 쉬울 것입니다.

 

JSR로의 공개

 

Fresh 관련 패키지가 JSR에 공개되었습니다.

 

(@fresh) 이 변경에 맞춰 Preact와 esbuild 등의 패키지가 esm.sh가 아닌 npm:을 통해 로드되도록 변경되었습니다.

 

이로 인해 Fresh 프로젝트에서 deno.lock을 더 쉽게 사용할 수 있을 것입니다.

 

Express와 유사한 API 제공

 

다음과 같이 명령형으로 라우팅이나 Island 등을 설정하기 위한 API가 추가됩니다.

 

이를 통해 Fresh의 플러그인에서 더 유연하게 설정을 커스터마이징할 수 있을 것입니다.

import { App, fsRoutes, trailingSlashes } from "@fresh/core";

const app = new App({ root: import.meta.url })
  // 미들웨어 설정
  .use(trailingSlashes("never"));

// 라우팅 설정
await fsRoutes(app, {
  loadIsland: (path) => import(`./islands/${path}`),
  loadRoute: (path) => import(`./routes/${path}`),
});

export { app };

 

createDefine() API

 

Fresh에서 핸들러나 페이지 컴포넌트를 쉽게 정의할 수 있도록 createDefine()이라는 API가 제공될 예정입니다.

define.ts
import { createDefine, page } from "fresh";

interface State {
  title: string;
}

const define = createDefine<State>();

export const handler = define.handlers({
  async GET(ctx) {
    const { title, content } = await readPost(ctx);
    ctx.title = title;
    return page({ content });
  },
});

export default define.page<typeof handler>(function PostPage(props) {
  return (
    <>
      <article>
        {props.data.content}
      </article>
    </>
  );
});

 

@fresh/core/compat

 

Fresh v1과의 호환성을 위한 레이어가 존재합니다.

 

Fresh v1을 사용한 프로젝트에서 Fresh v2의 알파 버전을 시험해보고 싶을 때 유용할 수 있습니다.

 

프로젝트 구성에 관한 변경

 

마이그레이션 가이드에 따르면 다음과 같은 변경 사항이 있을 것 같습니다.

• fresh.gen.ts/fresh.config.ts의 삭제
• 사전 빌드의 필수화

마이그레이션 가이드

현 시점에서 최신 마이그레이션 가이드는 다음 링크에서 확인할 수 있습니다.

 

이 페이지에서도 Fresh v2에서 어떤 변경이 예상되는지 설명하고 있습니다.

 

맺음말

Deno v2는 곧 나올 것 같은 분위기가 있지만, 언제 나올지는 아직 확실치 않습니다.

 

그러나 작년부터 마이그레이션 가이드를 준비하거나 DENO_FUTURE 환경 변수를 도입하는 등의 준비가 진행되고 있어, Deno v2를 향한 대응이 착실히 진행되고 있는 것으로 보입니다.

 

개인적으로는 Deno v2를 위해 개발 중인 워크스페이스 기능이 매우 유용할 것 같아 기대가 큽니다.

---

이상으로 Deno v2, deno_std v1, Fresh v2에 관한 최신 정보를 정리해 보았습니다.

 

앞으로의 업데이트를 기대하며, Deno 생태계의 발전을 계속 지켜봐 주시기 바랍니다.