[9월 3주차 주간회고] 나만의 eslint 규칙 만들기, Hello Node, Hello Express!

나만의 ESLint 규칙 만들기

결과물

eslint-config-ham-javascript

 

배경

• ESLint는 문법적인 오류나 안티 패턴을 찾아주기 때문에, 코드의 품질을 향상시킬 수 있다.
• 그러나 매번 작성하는 것은 번거롭다.
• 그렇다고 eslint-config-airbnb 만을 도입하기엔 너무 규칙이 엄격했다. 추가적인 규칙 설정이 필수였다.
• 심지어 아직 최신 버전으로 마이그레이션되지 않은 것으로 보인다. 마지막 업데이트가 3년 전!!

• 그래서 매번 세팅하지 않아도 의존성 하나로 해결이 가능하며, 규칙도 내 입맛대로 만들 수 있고, 최신 ESLint도 사용할 수 있도록 나만의 ESLint 규칙을 만들어 보기로 했다.

 

아직도 .eslintrc.* 쓰시나요?

eslint 는 v9부터 eslint.config.js 형태로 통일된 flat config를 구성 파일로 채택했다. 이제 계층 구조 없이 flat하게 여러 구성들을 객체로 펼쳐서 표현한다! 향후 유지보수를 위해 airbnb 폴더구조를 가져와 flat config로 마이그레이션하였다. 또한 불필요한 규칙들은 삭제, 필요한 규칙들을 추가했다.

const globals = require("globals");
const bestPractices = require("./rules/best-practices");
const errors = require("./rules/errors");
const style = require("./rules/style");
const variables = require("./rules/variables");
const es6 = require("./rules/es6");
const imports = require("./rules/imports");
const strict = require("./rules/strict");

module.exports = [
  ...bestPractices,
  ...errors,
  ...style,
  ...variables,
  ...es6,
  ...imports,
  ...strict,
  {
    languageOptions: {
      ecmaVersion: 2022,
      sourceType: "module",
      globals: {
        ...globals.browser,
        ...globals.node,
        ...globals.es6,
        ...globals.commonjs,
        ...globals.jest,
        html: "readonly",
      },
    },
    rules: {
    	/* ... */
    }
 }
];

 

ESLint로 FSD 폴더구조 규칙 제한하기

• FSD 폴더구조를 도입하고자 했는데, 아래와 같은 제한이 있었다.
  • 상위에서 하위 요소를 import 하는 것만 가능 (추상화, 다형성, 상속)
  • index.ts 적극 활용. export 한 컴포넌트만 사용하기 (캡슐화)
• 계층을 매번 생각하고 import 해오는 것에 어려움을 겪어서, 특정 경로의 import를 막을 수 있는 no-restricted-paths 룰을 사용하여 하위에서 상위 import를 막아주었다.

"import/no-restricted-paths": [
"error",
{
  zones: [
    {
      target: "./src/pages",
      from: "./src/app",
    },
    {
      target: "./src/widgets",
      from: ["./src/app", "./src/pages"],
    },
   	/* ... */
  ],
 },
]

 

JSDoc 사용하기

• TS로의 마이그레이션을 염두에 두고 있고, 타입체킹 없이 코드를 작성하는 데 불편함이 있어 JSDoc을 사용하기로 했다.
• 이를 위해 ESLint에도 플러그인을 활용해서 모든 함수, 공용 클래스의 JSDoc 작성을 강제했다.

 

회고

잘한 것은 무엇인가?

• 리액트 스터디에서 공부했던 부분을 진행하는 프로젝트에 맞게 적용하려는 시도가 좋았던 것 같다!

해결해야할 문제/남아있는 의문은 무엇인가?

• 범용성이 떨어질 수 있다. (src 를 루트로 상정)
• 다른 언어/프레임워크/라이브러리로의 확장이 필요하다.
  • eslint-config-ham-typescript
  • eslint-config-ham-react
  • eslint-config-ham-next
• 아직 모든 규칙을 확인하지 못했다.

어떻게 개선할 것인가?

• 프로젝트를 진행하며 필요한 부분을 추가 및 삭제하고, 틈틈이 미처 확인하지 못한 룰들을 살펴본다.
• src를 루트로 제한하지 않도록 리팩토링한다. 이후 사용하는 측에서 config 파일의 위치를 조정한다.

 

Hello Node, Hello Express!

결과물

API 만들기, 테스트 완료!!

 

배경

• 개인프로젝트를 진행하며, API를 연동해서 상황에 따른 성능 확인이 필요했다.
• 슬프게도 나는 장고 이외의 백엔드 지식이 없었기 때문에, 스스로 아직 API를 만들 수 없었다.
• 묵혀두었던 노드 강의를 듣고 간단한 API를 만들어 보고자 했다.

 

회고

무엇을 배웠는가?

• Node.js 교과서 강의를 들으며 아래 내용들을 배웠다.
  • 노드의 기본 기능 익히기
  • http 모듈로 서버 만들기
  • MySQL 및 시퀄라이즈 시작하기
• 구글링 및 강의에서 배운 내용을 바탕으로 User 와 Post 모델만을 가진 간단한 API를 만들어보았다.

잘한 것은 무엇인가?

백엔드 기피증 치료하기

해결해야할 문제/남아있는 의문은 무엇인가?

• 작년 강의라 아마 더 좋은 방법들이 나왔을수도 있고, 기능이 바뀌었을수도 있는데 이를 고려하지 못했다.
• 공식문서를 읽다 말았다.
• 개인프로젝트를 위한 API이므로 모노레포 세팅이 더 적합했을 것 같지만... 아무 생각 없이 강의를 따라했다.
• Vercel로 배포를 예정하고 있었는데, Vercel 에서는 Sequelize 를 지원하지 않고 있었다!

어떻게 개선할 것인가?

• 가벼운 API를 만들 수 있는 여러 라이브러리 찾아보기
•  모노레포 도입 고민하기
• 찾아보니 Vercel 자체내에서 제공하는 DB를 이용할 수 있게 되어있다. 그중에서도 SQL을 사용하는 Vercel Postgres 를 써볼 수 있을 듯하다. Sequelize to Postgres 마이그레이션 비용과, AWS 배포 비용 중 어느 것이 더 클지 잘 생각하고 해결해 보자.