(빌드) 도구 없이 웹 개발
- WBOY원래의
- 2024-08-05 19:11:221091검색
JavaScript가 사용될 새로운 웹 프로젝트를 시작할 때 가장 먼저 하는 일은 빌드 및 개발자 도구를 설정하는 것입니다. 예를 들어, 요즘 유행하는 Vite. 모든 JavaScript(웹) 프로젝트에 복잡한 빌드 도구가 필요하지 않다는 사실을 알지 못할 수도 있습니다. 사실, 이 기사에서 보여주듯이 이제 그 어느 때보다 없이 지내기가 더 쉬워졌습니다.
index.html 파일로 새 프로젝트를 생성하세요.
<!doctype html>
<html>
<head>
</head>
<body>
<p>Hello world</p>
</body>
</html>
VS Code를 사용하는 경우 실시간 미리 보기 확장을 설치하세요. 실행하세요. 이것은 실시간 재로드 기능을 갖춘 간단한 파일 서버입니다. 모든 파일 서버를 사용할 수 있습니다. Python에는 다음이 내장되어 있습니다.
python3 -m http.server
실시간 미리보기는 파일을 변경한 후 페이지를 자동으로 새로 고치기 때문에 마음에 듭니다.
이제 브라우저에서 index.html 파일에 액세스하여 "Hello world"를 볼 수 있습니다.
다음으로 index.js 파일을 만듭니다.
console.log("Hello world");
export {};
index.html에 포함하세요.
<script type="module" src="./index.js"></script>
브라우저에서 개발자 콘솔을 엽니다. "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의 헤드 섹션에 가져오기 맵을 추가할 수 있습니다.
<script type="importmap">
{
"imports": {
"superstruct": "https://esm.sh/superstruct@1.0.4"
}
}
</script>
이제
를 사용하여 이 패키지를 간단히 가져올 수 있습니다.
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년도 채 되지 않은 빌드 도구를 업데이트하는 데 따른 어려움을 알고 계실 것입니다. 이 프로젝트 설정으로 귀하는 같은 운명을 겪지 않을 것입니다.
Testing
If your JavaScript does not depend on browser APIs, you could just use the test runner that comes bundled with Node.js. But why not write your own test runner that runs right in the browser?
/** @type {[string, () => Promise<void> | void][]} */
const tests = [];
/**
*
* @param {string} description
* @param {() => Promise<void> | 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);
}
Now create a file example.test.js.
import { test, assert } from "@/test.js";
test("1+1", () => {
assert(1 + 1 === 2);
});
And a file where you import all your tests:
import "./example.test.js";
console.log("This should only show up when running tests");
Run this on page load:
await import("@/test/index.js"); // file that imports all tests
(await import("@/test.js")).runAllTests();
And you got a perfect TDD setup. To run only a section of the tests you can comment out a few .test.js import, but test execution speed should only start to become a problem when you have accumulated a lot of tests.
Benefits
Why would you do this? Well, using fewer layers of abstraction makes your project easier to debug. There is also the credo to "use the platform". The skills you learn will transfer better to other projects. Another advantage is, when you return to a project built like this in 10 years, it will still just work and you don't need to do archeology to try to revive a build tool that has been defunct for 8 years. An experience many web developers that worked on legacy projects will be familiar with.
See plainvanillaweb.com for some more ideas.
위 내용은 (빌드) 도구 없이 웹 개발의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!