JavaScript가 사용될 새 웹 프로젝트를 시작할 때 가장 먼저 하는 일은 빌드 및 개발자 도구를 설정하는 것입니다. 예를 들어, 요즘 유행하는 Vite. 모든 JavaScript(웹) 프로젝트에 복잡한 빌드 도구가 필요하지 않다는 사실을 알지 못할 수도 있습니다. 사실, 이 기사에서 보여주겠지만 이제는 그 어느 때보다 없이 지내기가 더 쉬워졌습니다.

index.html 파일로 새 프로젝트를 만듭니다.

  
  
  
    
Hello world
  

VS Code를 사용하는 경우 실시간 미리 보기 확장을 설치하세요. 실행하세요. 이것은 실시간 재로드 기능을 갖춘 간단한 파일 서버입니다. 모든 파일 서버를 사용할 수 있습니다. Python에는 다음이 내장되어 있습니다:

python3 -m http.server

실시간 미리보기가 파일을 변경한 후 자동으로 페이지를 새로 고치기 때문에 마음에 듭니다.

이제 브라우저에서 index.html 파일에 액세스하여 "Hello world"를 볼 수 있습니다.

다음으로 index.js 파일을 만듭니다.

console.log("Hello world");

export {};

index.html에 포함하세요:

브라우저에서 개발자 콘솔을 엽니다. "Hello world"가 보이면 제대로 로딩되고 있는 것입니다.

브라우저는 이제 ECMAScript 모듈을 지원합니다. 부작용 때문에 다른 파일을 가져올 수 있습니다:

import "./some-other-script.js";

또는 수출용

import { add, multiply } "./my-math-lib.js";

정말 멋지죠? 자세한 내용은 위의 MDN 가이드를 참조하세요.

패키지

바퀴를 다시 만들고 싶지 않을 것이므로 프로젝트에서 일부 타사 패키지를 사용할 수도 있습니다. 그렇다고 지금 패키지 관리자를 사용해야 한다는 의미는 아닙니다.

데이터 검증을 위해 superstruct를 사용한다고 가정해 보겠습니다. 우리 자신의 (로컬) 파일 서버뿐만 아니라 어떤 URL에서도 모듈을 로드할 수 없습니다. esm.sh는 npm에서 사용 가능한 거의 모든 패키지에 대한 모듈을 편리하게 제공합니다.

https://esm.sh/superstruct를 방문하면 최신 버전으로 리디렉션되는 것을 확인할 수 있습니다. 코드에 다음과 같이 이 패키지를 포함할 수 있습니다.

import { assert } from "https://esm.sh/superstruct";

안전을 원할 경우 버전을 고정할 수 있습니다.

유형

당신은 어떤지 모르겠지만 TypeScript는 나를 망치고 게으르게 만들었습니다. 유형 검사기의 도움 없이 일반 JavaScript를 작성하는 것은 줄타기를 하는 것처럼 느껴집니다. 다행히도 유형 검사를 생략할 필요는 없습니다.

이제 npm을 폐기할 시간입니다(비록 제공하는 코드는 제공하지 않지만).

npm init --yes
npm install typescript

JavaScript 코드에서 TypeScript 컴파일러를 사용할 수 있습니다! 이에 대한 일류 지원이 있습니다. jsconfig.json을 생성합니다:

{
  "compilerOptions": {
    "strict": true,
    "checkJs": true,
    "allowJs": true,
    "noImplicitAny": true,
    "lib": ["ES2022", "DOM"],
    "module": "ES2022",
    "target": "ES2022"
  },
  "include": ["**/*.js"],
  "exclude": ["node_modules"]
}

이제 실행하세요

npm run tsc --watch -p jsconfig.json

코드에 유형 오류가 발생합니다. TypeScript 컴파일러는 다음을 불평해야 합니다:

/** @type {number} **/
const num = "hello";

그런데 위에 보이는 댓글은 JSDoc입니다. 이런 방식으로 JavaScript에 유형을 추가할 수 있습니다. TypeScript를 사용하는 것보다 조금 더 장황하지만 꽤 빨리 익숙해집니다. 이는 또한 매우 강력합니다. 미친 유형을 작성하지 않는 한(대부분의 프로젝트에서는 작성하지 않아야 함) 괜찮습니다.

복잡한 유형(도우미)이 필요한 경우 언제든지 .d.ts 파일에 일부 TypeScript를 추가할 수 있습니다.

JSDoc은 대규모 JavaScript 프로젝트를 진행 중인 사람들이 점진적으로 TypeScript로 마이그레이션할 수 있도록 하는 디딤돌에 불과합니까? 나는 그렇게 생각하지 않는다! TypeScript 팀은 또한 곧 출시될 TypeScript 릴리스와 같이 JSDoc TypeScript에 훌륭한 기능을 계속 추가하고 있습니다. 자동 완성은 VS Code에서도 훌륭하게 작동합니다.

지도 가져오기

빌드 도구 없이 프로젝트에 외부 패키지를 추가하는 방법을 배웠습니다. 그러나 코드를 많은 모듈로 분할하는 경우 전체 URL을 계속해서 작성하는 것은 다소 장황할 수 있습니다.

index.html의 헤드 섹션에 가져오기 맵을 추가할 수 있습니다.

이제
를 사용하여 이 패키지를 간단히 가져올 수 있습니다.

import {} from "superstruct"

'일반' 프로젝트와 같습니다. 또 다른 이점은 패키지를 로컬에 설치하면 유형 완성 및 인식이 예상대로 작동한다는 것입니다.

npm install --save-dev superstruct

node_modules 디렉토리의 버전은 사용되지 않습니다. 이를 제거해도 프로젝트는 계속 실행됩니다.

제가 즐겨 사용하는 비결은 다음을 추가하는 것입니다.

      "cdn/": "https://esm.sh/",

내 가져오기 맵으로. 그런 다음 esm.sh를 통해 사용 가능한 모든 프로젝트를 간단히 가져오기하여 사용할 수 있습니다. 예:

import Peer from "cdn/peerjs";

이 유형의 가져오기 개발을 위해 node_modules에서 유형을 가져오려면 jsconfig.json의 컴파일러 옵션에 다음을 추가해야 합니다.

    "paths": {
      "cdn/*": ["./node_modules/*", "./node_modules/@types/*"]
    },

전개

프로젝트를 배포하려면 모든 파일을 정적 파일 호스트에 복사하면 완료됩니다! 레거시 JavaScript 프로젝트에 참여해 본 적이 있다면 1~2년도 채 되지 않은 빌드 도구를 업데이트하는 데 따른 어려움을 알고 계실 것입니다. 이 프로젝트 설정으로 인해 귀하는 동일한 운명을 겪지 않을 것입니다.

테스트

JavaScript가 브라우저 API에 의존하지 않는 경우 Node.js와 함께 번들로 제공되는 테스트 실행기를 사용할 수 있습니다. 하지만 브라우저에서 바로 실행되는 자체 테스트 실행기를 작성해 보는 것은 어떨까요?

/** @type {[string, () => Promise | void][]} */
const tests = [];

/**
 *
 * @param {string} description
 * @param {() => Promise | void} testFunc
 */
export async function test(description, testFunc) {
  tests.push([description, testFunc]);
}

export async function runAllTests() {
  const main = document.querySelector("main");
  if (!(main instanceof HTMLElement)) throw new Error();
  main.innerHTML = "";

  for (const [description, testFunc] of tests) {
    const newSpan = document.createElement("p");

    try {
      await testFunc();
      newSpan.textContent = `✅ ${description}`;
    } catch (err) {
      const errorMessage =
        err instanceof Error && err.message ? ` - ${err.message}` : "";
      newSpan.textContent = `❌ ${description}${errorMessage}`;
    }
    main.appendChild(newSpan);
  }
}

/**
 * @param {any} val
 */
export function assert(val, message = "") {
  if (!val) throw new Error(message);
}

이제 example.test.js 파일을 만듭니다.

import { test, assert } from "@/test.js";

test("1 1", () => {
  assert(1   1 === 2);
});

그리고 모든 테스트를 가져오는 파일:

import "./example.test.js";

console.log("This should only show up when running tests");

페이지 로드 시 다음을 실행하세요.

await import("@/test/index.js"); // file that imports all tests
(await import("@/test.js")).runAllTests();

완벽한 TDD 설정을 갖추었습니다. 테스트의 일부 섹션만 실행하려면 몇 가지 .test.js 가져오기를 주석 처리할 수 있지만, 테스트 실행 속도는 많은 테스트를 축적한 후에만 문제가 되기 시작해야 합니다.

이익

왜 이런 일을 하시겠습니까? 글쎄, 더 적은 수의 추상화 계층을 사용하면 프로젝트를 디버그하기가 더 쉬워집니다. "플랫폼을 사용하라"는 신조도 있습니다. 당신이 배우는 기술은 다른 프로젝트로 더 잘 전달될 것입니다. 또 다른 장점은 10년 후에 이와 같이 구축된 프로젝트로 돌아오면 여전히 작동할 것이며 8년 동안 사용되지 않은 빌드 도구를 부활시키려고 고고학을 할 필요가 없다는 것입니다. 레거시 프로젝트에 참여했던 많은 웹 개발자들이 익숙할 경험입니다.

더 많은 아이디어를 보려면 plainvanillaweb.com을 참조하세요.