TypeScript Deep Dive
  • README
  • 시작하기
    • 왜 타입스크립트인가
  • 자바스크립트
    • 비교 연산자
    • 참조 연산자
    • Null vs. Undefined
    • this
    • 클로저
    • Number
    • Truthy
  • 미래의 자바스크립트
    • 클래스
      • 즉시실행함수
    • 화살표 함수
    • 나머지 연산자
    • let
    • const
    • 비구조화 할당
    • 전개 연산자
    • for...of
    • 이터레이터
    • 템플릿 리터럴
    • 프로미스
    • 제네레이터
    • Async Await
  • 프로젝트
    • 컴파일러 제어
      • tsconfig.json
      • 파일 경로 지정
    • 선언
    • 모듈화
      • 파일을 이용한 모듈화
      • globals.d.ts
    • 네임스페이스
    • 동적 표현식 가져오기
  • Node.js 시작하기
  • Browser 시작하기
  • 타입스크립트 타입 시스템
    • 자바스크립트 마이그레이션 가이드
    • @types
    • 주변 선언
      • 파일 선언
      • 변수
    • 인터페이스
    • 열거형(Enums)
    • lib.d.ts
    • 함수
    • 콜러블(Callable)
    • 타입 표명(Type Assertion)
    • 신선도(Freshness)
    • 타입 가드
    • 리터럴(Literal)
    • 읽기 전용(readonly)
    • 제네릭
    • 타입 인터페이스
    • 타입 호환성
    • Never 타입
    • 구별된 유니온
    • 인덱스 서명(Index Signature)
    • 타입 이동하기
    • 예외 처리
    • 믹스인(Mixin)
  • JSX
    • React
    • Non React JSX
  • Options
    • noImplicitAny
    • strictNullChecks
  • 타입스크립트 에러
    • 에러 메세지
    • 공통 에러
  • NPM
  • 테스트
    • Jest
    • Cypress
  • Tools
    • Prettier
    • Husky
    • ESLint
    • Changelog
  • 팁
    • 문자열 Enums
    • 타입 단언
    • 상태 저장 함수
    • 커링
    • 제네릭 타입 예시
    • 객체 타입 설정
    • 유용한 클래스
    • Import / Export
    • 속성 Setters
    • outFile 주의사항
    • 제이쿼리 팁
    • 정적 생성자
    • 싱글톤 패턴
    • 함수 파라미터
    • 토글 생성
    • Import 여러개 하기
    • 배열 생성
    • 생성자에서 타입정의
  • 스타일 가이드
  • 타입스크립트 컴파일러 구조
    • Program
    • AST
      • TIP: Visit Children
      • TIP: SyntaxKind enum
      • Trivia
    • Scanner
    • Parser
      • Parser Functions
    • Binder
      • Binder Functions
      • Binder Declarations
      • Binder Container
      • Binder SymbolTable
      • Binder Error Reporting
    • Checker
      • Checker Diagnostics
      • Checker Error Reporting
    • Emitter
      • Emitter Functions
      • Emitter SourceMaps
    • Contributing
Powered by GitBook
On this page
  • Quick common setup
  • Installing a package
  • Installing a devDependency
  • Security
  • NPM Scripts
  • What is with -- in scripts
  • Public vs. Private packages
  • Public packages
  • Private packages

Was this helpful?

NPM

Previous공통 에러Next테스트

Last updated 3 years ago

Was this helpful?

Fun fact npm is so it doesn't expand to anything, but among friends it is commonly called node package manager.

npm is a binary that comes with default node installations used to manage community shared JavaScript / TypeScript packages.

  • NPM packages are hosted at (and installed from) (the ☁️).

Quick common setup

  • npm packages are configured using package.json file. You can generate a quick file using npm init -y.

  • packages get installed into a ./node_modules folder. You normally have this folder in your .gitignore.

Even though you might be building an application, having a package.json essentially makes your project a package as well. So the terms your project | package can be used interchangeably.

When you checkout someone's (your team's) package, it will have a package.json that will list the dependencies you need to run the project. You simply run npm install and npm will bring them down from the cloud ☁️.

Installing a package

You can run npm install <something>. Most people will use the shorthand npm i <something> e.g.

// Install react
npm i react

This will also automatically add react into your package.json's dependencies.

Installing a devDependency

devDependencies are dependencies that are only required during development if your project and not required after deployment.

typescript is common in devDependencies as its only required to build .ts -> .js. You normally deploy the built .js files:

  • into production

  • OR for consumption by other other npm packages

Security

The public npm packages are scanned by security team worldwide and issues get reported to npm team. They then release security advisories detailing the issue and potential fixes. Commonly the fix is simply updating the package.

You can run an audit on your node project by simply running npm audit. This will highlight any vulnerabilities that might exist in the package / dependencies of the package. e.g.

┌───────────────┬──────────────────────────────────────────────────────────────┐
│ Low           │ Regular Expression Denial of Service                         │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package       │ debug                                                        │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ jest [dev]                                                   │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path          │ jest > jest-cli > istanbul-lib-source-maps > debug           │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info     │ https://nodesecurity.io/advisories/534                       │
└───────────────┴──────────────────────────────────────────────────────────────┘

Note that commonly the issues are found in development dependencies (e.g. jest in this case). Since these aren't are a part of your production deployments, most likely your production application is not vulnerable. But still good practice to keep vulnerabilities to 0.

Simply add npm audit (the command exist with error code 1 in case of error) as a part of your deployment to ensure the projects stay up to date.

NPM Scripts

What is with -- in scripts

You can build a base script with a limited set of command line arguments e.g. here is a script target that runs tsc for the TypeScript compiler:

{
  "scripts": {
    "build": "tsc -p ."
  }
}

You can create a build:watch target to run tsc -p . -w or alternatively asking npm to run build with the additional -w flag like so:

{
  "scripts": {
    "build": "tsc -p .",
    "build:watch": "npm run build -- -w"
  }
}

You can pass in as many flags as you want after -- e.g. in the following example build:more has the same effect as something --foo -f -d --bar

{
  "scripts": {
    "build": "something --foo",
    "build:more": "npm run build -- -f -d --bar"
  }
}

Public vs. Private packages

You don't need this when using any of the common public npm packages. Just know its there for enterprise / commercial customers.

Public packages

  • Packages are public by default.

  • Anyone can deploy a package to npm.

  • You just need an account (which you can get for free).

No one needs an account to download a public package.

This free sharing of packages is one of the key reasons of success for npm 🌹.

Private packages

Of-course you need an account with the right permissions to download a private package.

If you want a private package for your company / team / enterprise you need to sign up to a paid plan, details here :

not an acronym
https://www.npmjs.com/
https://www.npmjs.com/pricing