1. substring

• 사용 방법은 여러 형태가 있다.

# 1
SELECT substring('abcdefg' FROM 2 FOR 3);  -- 결과: 'bcd'

# 2
SELECT substring('abc123def' FROM '[0-9]+');  -- 결과: '123'

# 3
SELECT substring('abcdefg', 2, 3);  -- 결과: 'bcd'

# 4
SELECT substring('abcdefg', length('abcdefg') - 3 + 1, 2); -- 결과: 'ef'

# 5
SELECT substring('abcdefg', length('abcdefg') - 3); -- 결과: 'defg'

• start : 시작 위치(인덱스가 1부터 시작)
• length : 추출할 문자의 수 즉, 몇 번째 부터 몇 번째가 아니라, start지점부터 문자의 수를 나타낸다

2. substr

substr도 동일한 기능을 하지만, substring의 경우가 더 많은 기능을 제공한다. 다만, 성능 면에서는 큰 차이가 없기에 그냥 편한걸로 사용하면 된다.

1. Spread 문법(...)

• 펼친다는 의미이며, 배열 또는 객체를 개별 요소로 분해해서 사용한다.
• iterable 객체에서 사용할 수 있기에 배열, 객체, Map, Set 또한 확장해서 사용이 가능하다.

// 배열에서 사용
const arr = ["a", "b", "c", "d"]
const arr2 = [...arr] // 배열의 얕은 복사.
const arr3 = [...arr, "e"] // 요소 추가.

// 객체에서 사용
const obj1 = { a: 1, b: 2 };
const obj2 = { ...obj1, c: 3 };  // { a: 1, b: 2, c: 3 }

// 함수 호출에 사용
function sum(a, b, c) {
  return a + b + c;
}

const nums = [1, 2, 3];
sum(...nums); // 6

2. Rest 문법(...)

• 나머지를 모은다는 의미로 함수의 인자나 객체/배열 구조 분해 시 남은 요소들을 하나의 변수로 수집한다.

// 배열 구조 분해에서 사용
const [first, ...rest] = [10, 20, 30, 40];
// first: 10
// rest: [20, 30, 40]

// 객체 구조 분해에서 사용
const { a, ...rest } = { a: 1, b: 2, c: 3 };
// a: 1
// rest: { b: 2, c: 3 }

function foo(a, ...rest) {
  console.log(rest) // ["a","b","c"]
}
foo("a", "b", "c", "d")

const obj = { a: 1, b: 2, c: 3 }
const { c, ...obj2 } = obj
console.log(c, obj2) // 3 {a: 1, b: 2}

• 조금 헷갈리긴 한데, 변수 할당 코드 줄이 있을 때 왼쪽에 ...이라면 Rest, 오른쪽이라면 펼치는 형태기 때문에 Spread라고 보면 괜찮지 않을까 싶다...? 의도가 더 중요해보이긴 한다.

메서드 호출

1) 메서드 정의
int call(String str, int age)

2) 호출
call("hello", 30)

인수(Argument)

• 여기서 "hello", 30처럼 넘기는 값을 영어로 Argument라고 하며 한글로는 인수 또는 인자라고 한다.

매개변수(parameter)

• 메서드 정의에서 String str, int age를 매개변수, 파라미터라고 한다. 메서드를 호출할 때 인수를 넘기면, 그 인수가 매개변수에 대입된다.

정리

• 인수는 메서드 내부로 들어가는 값을 의미
• 매개변수는 메서드 호출부와 메서드 내부 사이에서 값을 전달하는 역할을 하는 변수
  • str = "hello", age = 30이며 인수가 매개변수로 되는 과정이라고 보면 될 것 같다

EXISTS

• 말 그대로 서브쿼리에서 반환하는 값이 존재하는지에 대한 여부를 판단해주는 역할을 한다.

  • 특정 조건의 일치 여부에 대해 true/false를 반환

• 주로 EXISTS를 사용하는 것이 성능이 좋다.

  • 찾는 조건이 하나라도 있으면 true 반환

• 종종 SELECT 1을 해주는데, 이유는 무슨 값을 넣어주던 상관 없기에 형식 상 1을 넣어준다

EXISTS vs IN 동작

• 존재하는 여부에 대해서 IN과 비교

[ EXISTS ]

SELECT *
FROM customers c
WHERE EXISTS (
    SELECT 1
    FROM orders o
    WHERE o.customer_id = c.id
);

[ IN ]
SELECT *
FROM customers
WHERE id IN (
    SELECT customer_id
    FROM orders
);

• 여기서 EXISTS가 IN보다 성능이 좋은 이유를 나열해보자
  • IN은 내부 쿼리를 먼저 모두 수행하고 나서 리스트로 만들고, 이후 외부 쿼리의 각 행이 포함되는지 비교한다.
  • SELECT customer_id FROM orders 에서 예를 들어 {1, 2, 5, 7}이 나왔다면
  • 외부 쿼리 ⇒ customers.id IN {1, 3, 4, 5, ...} 에서 고객들이 포함됐는지, 안됐는지 비교해서 반환을 해준다.
  • 반면, EXISTS는 외부쿼리에서 내부쿼리로 하나씩 검사한다.
    • 각 행마다 하위 쿼리를 실행해서 만족하는 행이 있는지 확인한다.
    • 외부 쿼리를 돌면서 customers의 n번 고객이 하위 쿼리에서 있다면 포함한다.
    • 그래서 이러한 동작형태에 따라 존재 여부 만 보기 때문에 보다 효율적이라고 한다.

EXISTS vs IN NULL

• IN의 경우 NULL이 포함되면 원하지 않는 결과가 나올 수 있다

1. ==와 ===의 비교

• ==는 타입을 자동으로 변환한 후에 비교한다.

undefined == 0 // false
undefined == 1 // false
undefined == NaN // false
undefined == null // true

• ===는 타입도 같고 값도 같아야 true를 반환한다.

  undefined === 0 // false
  undefined === 1 // false
  undefined === undefined // true

2. 비교연산자(<, >, <=, >=)

• 이 경우에는 숫자로 변환되어 비교된다.

  * undefined는 숫자로 변환되면 NaN이 된다

• Number(undefined) => NaN, NaN은 어떤 수와도 비교할 수 없다.

undefined > 0        // false
undefined < 0        // false
undefined >= 0       // false
undefined <= 0       // false

Number(undefined)    // NaN
NaN > 0              // false
NaN < 0              // false
NaN == NaN           // false

3. isNaN(), Number.isNaN()

• Number.isNaN()은 정확하게 NaN인 값만 true를 반환한다. undefined는 타입이 undefined이고, 숫자도 아니며 자기 자신과 같다. 그리고 NaN이 아니라 false를 반환한다.

• 그렇기에 Number.isNaN(undefined) // false

• isNaN(undefined) // true

• 왜 true냐면, isNaN()는 타입을 먼저 숫자로 변환하기 때문이다.

  1. Number(undefined) // NaN
  2. isNaN(NaN) // true

• 위와 같은 프로세스를 거치기 때문에 true가 나오는 것이다.

4. 추가 궁금증

NaN == NaN       // false
NaN === NaN      // false
undefined == null     // true
undefined === null    // false

• 동등 연산자(==, ===)에서 NaN을 각각 할 때 왜 false냐면, NaN은 자기 자신과도 같지 않다라는 성질을 가지고 있기에 비교 시에는 전용 함수(Number.isNaN, isNaN)을 활용해야한다.

• undefined와 null의 ==비교는 자바스크립트에서 예외적으로 true를 반환해준다. 다만, undefined === null은 엄격하게 판단한다.

• undefined의 타입은 undefined, null의 타입은 object여서 타입이 다르기 때문에 false이다.

flex-grow

• grow는 해당 요소가 Flexbox 레이아웃 안에서 남는 공간을 차지하게 만든다.

flex-grow: 1; // grow 요소가 가능한 한 남는 공간을 차지함
flex-grow: 0; // grow-0 요소가 남는 공간을 전혀 차지하지 않음(default)

[ grow - 남는 공간 차지할 때 ]

<div class="flex">
  <div class="bg-red-500">고정 너비</div>
  <div class="grow bg-green-500">남는 공간을 채움</div>
</div>

[ grow-0 - 남는 공간 차지하지 않을 때 ]

<div class="flex">
  <div class="bg-red-500">고정 너비</div>
  <div class="grow-0 bg-green-500">남는 공간을 채움</div>
</div>

flex-shrink

• 컨테이너 공간이 부족할 때 항목이 줄어드는 비율을 설정한다.
• default : 1(공간이 부족하면 줄어들 수 있음)
• 0 : 줄어들지 않음(항상 원래 너비 유지)

<div class="flex w-40">
  <div class="shrink-0 w-32 bg-red-500">A</div>
  <div class="w-32 bg-blue-500">B</div>
</div>

• w-40 : 160px인데, 각 두 요소가 128px이나 사진 상으로는 A는 줄지 않고, B는 줄어든다.

flex-basis

• Flex 항목의 초기 크기(기본 크기)를 설정. Flexbox 내부에서만 작동

<div class="flex">
  <div class="basis-1/3 bg-green-500">33%</div>
  <div class="basis-2/3 bg-yellow-500">66%</div>
</div>

이외

• 번외로 gap은 Flexbox나 Grid 레이아웃에서 자식 요소 간의 간격을 설정할 때 사용한다.

• CSS를 직접 쓰는 경우 flex: [flex-grow] [flex-shrink] [flex-basis];

  flex: 1 1 0%;  /* grow: 1, shrink: 1, basis: 0% */

• 여러가지 필요한 경우가 있으면 gpt와 함께 찾아보자

Promise.all

• 모든 프로미스가 성공해야 결과를 반환한다.
• 하나라도 실패하면 reject

// [ 성공 예시 ]
const p1 = Promise.resolve(1);
const p2 = Promise.resolve(2);
const p3 = Promise.resolve(3);

Promise.all([p1, p2, p3])
  .then(results => {
    console.log('All success:', results); // [1, 2, 3]
  })
  .catch(err => {
    console.error('One failed:', err);
  });

// [ 실패 예시 ]
const p1 = Promise.resolve(1);
const p2 = Promise.reject('Error!');
const p3 = Promise.resolve(3);

Promise.all([p1, p2, p3])
  .then(results => {
    console.log('All success:', results);
  })
  .catch(err => {
    console.error('One failed:', err); // 'Error!'
  });

Promise.allSettled

• 모든 프로미스의 성공/실패 여부와 관계없이 결과를 수집

  const p1 = Promise.resolve(1);
  const p2 = Promise.reject('Failed');
  const p3 = Promise.resolve(3);
  

Promise.allSettled([p1, p2, p3]) .then(results => { console.log(results); /* [ { status: 'fulfilled', value: 1 }, { status: 'rejected', reason: 'Failed' }, { status: 'fulfilled', value: 3 } ] */ });

```

• 개발하고 싶은 로직에 따라 원하는 것을 택해서 사용하면 된다

some()

• 하나라도 조건을 만족하면 true를 반환한다.

const numbers = [1, 3, 5, 8, 11];

const hasEven = numbers.some(num => num % 2 === 0);

console.log(hasEven); // ✅ true (8이 짝수이므로)

• 그러면 8에서 끝나고 반환해준다.

every()

• 하나라도 조건을 만족하지 않으면 즉시 중단 후 false 반환

// 1번째 예시
const numbers = [1, 2, 3, 4];

const allPositive = numbers.every(num => num > 0);

console.log(allPositive); // ✅ true

// 2번째 예시
const hasNegative = [1, -2, 3].every(num => num > 0);
console.log(hasNegative); // ❌ false (-2 때문에 중단)

• 1번째는 전부 순회하나 2번째는 -2에서 중단된다.

비교

• 둘 다 Boolean형태로 값을 반환한다.

GPT 예시를 참고한다.

[ 연속해서 then, catch쓴 경우 ]

Promise.resolve('start')
  .then((r1) => {
    console.log('1단계:', r1);
    return '2단계 데이터';
  })
  .then((r2) => {
    console.log('2단계:', r2);
    // 여기서 에러 발생
    throw new Error('2단계 에러!');
    return '3단계 데이터';
  })
  .then((r3) => {
    console.log('3단계:', r3);
  .catch((err) => {
    console.error('잡은 에러:', err.message);
  });

• 위의 경우 2단계에서 에러가 났으니 catch문으로 이동하여 에러를 발생시킨다.
• 그 이후 3단계 데이터는 진행하지 않는다.

[ 중첩되는 경우 ]

Promise.resolve('시작')
  .then((result1) => {
    console.log('1단계:', result1);
    return Promise.resolve('2단계 데이터');
  })
  .then((result2) => {
    console.log('2단계:', result2);
    return Promise.resolve('3단계 데이터')
      .then((innerResult) => {
        console.log('3단계(안쪽):', innerResult);
        // 여기서 에러를 발생시켜볼게
        throw new Error('3단계에서 문제 발생!');
      });
  })
  .then((result3) => {
    console.log('4단계:', result3);
    return '4단계 완료';
  })
  .catch((err) => {
    console.error('에러를 잡았다!', err.message);
  });

• 이 경우에는 throw new Error('3단계에서 문제 발생!');에서 발생이 되는데, 여기서 가까운 catch문으로 이동하여 "에러를 잡았다! 3단계에서 문제 발생!" 출력

• 마찬가지로 4단계 then은 실행을 안한다.

• 추가적으로 return을 안해주면 then이 이어지면서 진행은 되나 매개변수에 전달되는 값은 undefined로 처리된다.

  .then((result2) => {
    console.log('2단계:', result2);
    return Promise.resolve('3단계 데이터')
      .then((innerResult) => {
        console.log('3단계(안쪽):', innerResult);
        throw new Error('3단계에서 문제 발생!');
      })
      .catch(() => {  // <<< 3단계 catch
        console.log('error!');
      });
  })

이렇게 중첩된 내부 안에서도 catch가 있으면 그 이후 4단계도 진행한다. 다만, 4단계에서 매개변수로 받는 result3는 undefined가 나온다.

• 해당 패키지는 typescript였다.

typescript는 CommonJS패키지

• typescript는 CommonJS패키지인데, CommonJS는 트리쉐이킹(Tree-shaking)이 거의 안된다.

import { isConstructorDeclaration } from 'typescript'

이와 같이 선언하고 사용을 안해도 빌드 시에는 포함되어서 사이즈가 늘어난다는 것이다.

ESM vs CommonJS

• Tree-shaking의 경우에는 안쓰는 코드를 제거해서 번들 사이즈를 줄이는데, ESM은 잘된다.

• ESM(ES Modules)은 태생적으로 정적(static) 구조 이기 때문이다.

  import { foo } from './utils.js'

• util.js를 불러오기 전에 어떤 export를 사용할지 정하고, 나머지는 필요없다고 번들러가 미리 계산하여 제거를 할 수 있기에 Tree-shaking이 잘 된다.

CommonJS는 반대로 동적(Dynamic)이라 분석이 어렵다

const utils = require('./utils')

• utils안에는 뭐가 있고 어떻게 쓸지를 번들러가 알 수 없다.
• 그렇기에 번들러는 안전하게 다 포함시키게 되는 것이다.

그래서 또다른 예시로 lodash가 있는데, lodash-es 패키지를 활용해서 트리쉐이킹에 사용하기도 한다.

정적 : 미리 읽고 계획을 세울 수 있음 동적 : 실행해보기 전에는 뭘 쓸지 모른다.

엄청 와닿지는 않을 수 있지만, 프로젝트 개발을 하면서 안쓰는 것은 지우고, 모듈시스템에서 패키지들을 잘 관리하여 필요한 것들만 번들링할 수 있도록 점검하는 것이 좋을 것 같다.

1. Vue에서 key가 하는 일

• Vue는 내부적으로 Virtual DOM을 사용해서 변경된 부분만 효율적으로 업데이트한다.

• 예를 들어 v-for를 사용하면 :key를 적용하는데, 리스트의 데이터가 변경되면 어떤 항목이 추가, 삭제 등이 되었는지 파악하여 최소한 DOM조작으로 업데이트를 한다.

• 그 외에 특정 컴포넌트를 강제로 리렌더링할 때 key를 사용하는데, 컴포넌트의 key값을 변경하면 Vue는 이를 새로운 컴포넌트 인스턴스로 인식하여 기존 컴포넌트를 제거한 다음 새로운 컴포넌트를 생성한다.

  • 즉, unmount 후 새로운 인스턴스를 생성(mount)

• key가 없다면 위치 기준으로 요소를 비교하기에 리렌더링 오류가 생길 수 있다.

<apexchart :key="chartKey" :options="chartOptions" :series="series" type="area" height="350" />

const forceRerender = () => {
  chartKey.value += 1; // key 변경 → 새로운 apexchart 컴포넌트 생성
};

• key값으로는 고유한 문자열이나 숫자를 사용하는게 좋다.

[ 단점 ]

• 리렌더링 비용이 증가한다. 새롭게 만들기 때문이다.

2. 정리

• Vue의 Virtual DOM알고리즘은 위치와 컴포넌트 타입이 같으면 재사용을 한다.
• 즉, 앞서 key를 적용안해도 바뀐다고 생각했지만 이전의 값이 남아있었던 것이 컴포넌트 위치는 동일하기 때문이지 않을까 싶다.
• 그래서 강제 리렌더링을 위해 key를 사용해서 새로운 컴포넌트로 만드는 과정을 거친다.

COALESCE 개념

• COALESCE는 병합한다는 의미를 가지고 있다.

  COALESCE(value1, value2, ..., valueN)

  => 왼쪽부터 차례로 NULL이 아닌 첫 번째 값을 반환

예시

SELECT COALESCE(NULL, NULL, 'Hello', 'World'); -- 결과: 'Hello'

SELECT COALESCE(NULL, 100, 200); -- 결과: 100

SELECT COALESCE(column_name, 'Default Value') FROM table_name;
-- column_name이 NULL이면 'Default Value'를 사용

• 어떤 값이 NULL일 때 다음 파라미터에 설정한 값을 반환하도록 할 수 있다.

NULL 방지를 할 수 있다.

왜 사용하는가?

• 조건을 동적으로 붙이기 쉽게 하기 위함이다. 편의성을 위함

  SELECT * FROM users
  WHERE 1=1
  AND age > 20
  AND gender = 'M'
  AND status = 'active'

  조건이 있든 없든 쉽게 추가하거나 뺄 수 있다.

예를 들어 안쓴다면 아래처럼

SELECT * FROM users
WHERE age > 20 AND gender = 'M' AND status = 'active'

사용하게 되니까 가독성? 측면에서는 위 예시가 더 낫다.

또한 동적 쿼리를 쓸 때도 유용하다고 하니 참고로 알아두자.

getAllColumns() -> 31버전부터는 getColumns()

• 컬럼에 정의된 모든 컬럼을 반환한다.
  • 숨겨진 컬럼도 포함한다.
• 내용은 같지만 31버전부터는 getColumns(), getAllColumns() deprecated!

getAllGridColumns()

• 현재 그리드에 표시된 모든 컬럼을 반환한다.
  • 숨겨진 컬럼은 포함하지 않는다.

📌 정리

- valueFormatter

• UI에 출력되는 값만 변경할 때 사용된다.
• 원본 데이터는 변경 되지 않으며 단순하게 보여지는 값만 포매팅 된다.
• 예를 들면 YYYYMMDD 날짜를 YYYY-MM-DD형태로보여주나 원본 값은 YYYYMMDD 그대로이다.

const columnDefs = [
  {
    headerName: "Price",
    field: "price",
    valueFormatter: (params) => {
      return `${params.value.toFixed(2)}`; // 100 → "100.00"
    },
  }
];

- valueGetter

• 컬럼에 표시될 값 자체를 동적으로 생성한다.
• 반환된 값이 해당 컬럼의 데이터 값으로 적용된다.
• 그래서 엑셀에도 내보내기할 때 그리드 변경된 값으로 할 시 valueGetter가 좋다.

const columnDefs = [
  {
    headerName: "Full Name",
    valueGetter: (params) => {
      return `${params.data.firstName} ${params.data.lastName}`;
    },
  }
];

- valueFormatter vs valueGetter

근데 이 중에서 ~ 혹은 ^이 붙어 있는 거를 보면서 어떤 의미를 알아보려 한다.

1. ^(Caret)

• 메이저 버전인 가장 왼쪽의 숫자를 기준으로 마이너 버전까지만 업데이트 허용

  • 메이저 버전이 0이면 안정적이지 않다고 간주하여 패치 버전만 업데이트 가능하다.

• 예시

  • "vue": "^3.2.0" -> 3.x.x 버전에서 3.2.0 이상, 4.0.0 미만까지 허용
  • "axios": "^0.21.0" -> 0.21.x 버전에서 0.21.0 이상, 0.22.0 미만까지 허용

• 즉, 0을 제외하고 마이너 버전까지 업데이트를 한다.

2. ~(Tilde)

• 주어진 마이너 버전 내에서만 변경을 허용한다.

• 예시

  • "express": "~4.17.0" → 4.17.x 버전에서 4.17.0 이상, 4.18.0 미만까지 허용
  • "lodash": "~0.21.3" → 0.21.x 버전에서 0.21.3 이상, 0.22.0 미만까지 허용

3. 차이

• 안정성을 위한다면 ~를 사용하여 보수적으로 관리하고, 최신 기능 반영 등에 신경쓴다면 ^를 사용한다.

• 이외에도 단순 버전 고정으로 유지를 할 수 있다.

개발을 하다보면 머릿속으로 "아 이렇게 짜면 될 거 같다"하면서 써내려가지만 막상 배열과 객체 등을 사용할 때 v-for와 v-if를 같이 활용할 때가 가끔 있습니다.

그러면 흐음.. 어떻게 바꿀까 하는 생각과 함께 왜 안될까 라는 생각이 들었습니다.

태생적으로 v-for가 우선순위를 가집니다.

즉, v-for로 먼저 렌더링이 되고 나서 v-if를 통해 필터링을 합니다.

그렇게 되면 불필요한 렌더링이 발생하여 성능 상 저하가 일어납니다.

예시

<template>
  <ul>
    <li v-for="item in activeItems" :key="item.id">{{ item.name }}</li>
  </ul>
</template>

<script>
export default {
  data() {
    return {
      items: [
        { id: 1, name: 'Item 1', isActive: true },
        { id: 2, name: 'Item 2', isActive: false },
        { id: 3, name: 'Item 3', isActive: true },
      ],
    };
  },
  computed: {
    activeItems() {
      return this.items.filter(item => item.isActive);
    },
  },
};
</script>

결과가 생각한대로 나오지만 내부적으로는 아래와 같이 흘러갑니다.

1. v-for로 items를 모두 렌더링
2. 각 항목에 대해 v-if 조건이 평가

그렇기에 데이터의 형식이나 v-for, v-if를 같은 선상에서 쓰지 않는 등의 과정을 통해 이것도 나름의 최적화를 하도록 해야 합니다.

d.ts는 무엇인가?

• type declare에서 따온 것으로 생각하면 되며 type을 정의하기 위해 존재하는 파일이다.
  • 즉, JS코드의 타입 정보를 이해할 수 있도록 도와준다.
• TS환경에서 타입 체킹이 필요한 타입들을 불러서 체크해야되기 때문에 @types로 시작되는 라이브러리들이 있는 이유이다.

shims-vue.d.ts

• Vue 파일을 Typescript 환경에서 인식할 수 있도록 도와주는 파일이다.

  • Typescript는 .vue 파일을 모듈로 인식하지 못하기 때문에 이를 해결하고자 위의 파일을 활용한다.

    // shims-vue.d.ts 예시
    declare module '*.vue' {
    import { DefineComponent } from 'vue';
    const component: DefineComponent<{}, {}, any>;
    export default component;
    }

  • 내용을 간략하게 보자면, DefineComponent는 Vue3에서 컴포넌트를 타입으로 정의하며 .vue 파일을 컴포넌트로 봤을 때 타입을

env.d.ts

• 환경 변수(process.env, import.meta.env) 타입을 정의하는 파일
• vite, next 등 타입 선언, 환경 설정, 커스텀 타입 등에 활용된다.
  • .env파일과 env.d.ts의 연결을 진행

shims-vue.d.ts vs env.d.ts

• 사실 둘의 비교를 통해 차이점을 알기는 어렵지만, .d.ts 파일이 뭔지, 파일이 존재하지만 어떤 역할을 하는지 알고자 글을 작성하였다.

dependencies

• 프로젝트가 실행될 때 반드시 필요한 패키지들이 들어가는 곳
• 배포 후 에도 해당 패키지들이 필요함

{
  "dependencies": {
    "vue": "^3.2.0",
    "axios": "^1.5.0"
  }
}

devDependencies

• 프로젝트를 개발할 때만 필요한 패키지들이 들어가는 곳
• 배포 시에는 필요하지 않기 때문에, 프로덕션 빌드에서는 제외

{
  "devDependencies": {
    "typescript": "^5.2.0",
    "eslint": "^8.50.0",
    "vite": "^4.3.0"
  }
}

Typescript는 왜 devDependencies?

• Typescript는 빌드(컴파일) 때만 필요하기 때문이다.
• 즉, 배포에는 컴파일된 Javascript 만 배포되기 때문

그러나

무조건적으로 어떤 패키지는 dependencies나 devDependencies에 속하지는 않는다.

통상적으로는 목적과 분류에 따라 다르겠지만, 예를 들어 Typescript를 런타임 때까지 필요한 어떤 프로젝트를 진행할 때 필요할 수도 있다.

그렇기에 패키지 관리를할 때 구분하여 정리하는 것이 필요해 보인다.

대표적으로 react 설치 시 cli(command line interface, 글자를 입력해 컴퓨터에 명령을 내리는 방식)를 npx로 활용하여 설치한다. npx create-react-app my-app

근데 여기서 왜 npm을 하지 않고 npx를 사용하는 것인가 ?

• npm
  • 노드 패키지 관리자이며 설치, 관리, 실행에 사용된다.
  • npm install 명령어로 로컬 또는 글로벌 패키지를 설치한다.
  • npm install -g lodash형태로 하면 -g 옵션이 글로벌 즉 시스템 전역에 패키지를 설치한다.
  • 반면 npm install의 경우 로컬 설치를 한다.
• npx
  • 5.2.0 npm 버전 이상에 포함된다.
  • 패키지 실행에 최적화가 된 도구이며 실행 편의성에 따라 글로벌 혹은 패키지를 설치하지 않고 바로 직접 호출을 해준다.

2. 명령어 비교

• 물론 둘 다의 명령어를 통해서 설치할 수 있다.

[ npm ]

npm install create-react-app
npx create-react-app my-app

• npm install은 프로젝트 디렉토리에 로컬로 설치된다.
• node_moudules 폴더에 저장, package.json에 기록된다.
• create-react-app을 로컬에 설치하고 나서 바로 실행시켜야 하는 번거로움과 불필요한 파일이 쌓이게 된다.
• 글로벌 설치인 경우에는 버전 관리가 필요하고, 별도로 삭제하지 않으면 계속 남아 있다.

[ npx ]

• 로컬, 글로벌 설치가 필요 없으며 최신 버전을 실행한다.

npx create-react-app my-app

• 그래서 위와 같이 프로젝트 초기 세팅에서 사용된다.

현재는 boilerplate를 만들고 있는데, Vue 기준으로 npx를 통해 만들게 되면 소개해보고자 한다.