Typescript
  • Introducão
  • Primeiros Passos
    • Por que TypeScript
  • JavaScript
    • Igualdade
    • Referências
    • Null vs. Undefined
    • this
    • Closure
    • Number
    • Truthy
  • Futuro JavaScript Agora
    • Classes
      • Classes Emit
    • Arrow Functions
    • Rest Parameters
    • let
    • const
    • Destructuring
    • Spread Operator
    • for...of
    • Iterators
    • Template Strings
    • Promise
    • Generators
    • Async Await
  • Project
    • Compilation Context
      • tsconfig.json
      • Which Files?
    • Declaration Spaces
    • Modules
      • File Module Details
      • globals.d.ts
    • Namespaces
    • Dynamic Import Expressions
  • Node.js QuickStart
  • Browser QuickStart
  • TypeScript's Type System
    • JS Migration Guide
    • @types
    • Ambient Declarations
      • Declaration Files
      • Variables
    • Interfaces
    • Enums
    • lib.d.ts
    • Functions
    • Callable
    • Type Assertion
    • Freshness
    • Type Guard
    • Literal Types
    • Readonly
    • Generics
    • Type Inference
    • Type Compatibility
    • Never Type
    • Discriminated Unions
    • Index Signatures
    • Moving Types
    • Exception Handling
    • Mixins
  • JSX
    • React
    • Non React JSX
  • Options
    • noImplicitAny
    • strictNullChecks
  • Errors in TypeScript
    • Interpreting Errors
    • Common Errors
  • NPM
  • Testing
    • Jest
    • Cypress
  • Tools
    • Prettier
    • Husky
    • Changelog
  • TIPs
    • String Based Enums
    • Nominal Typing
    • Stateful Functions
    • Bind is Bad
    • Currying
    • Type Instantiation
    • Lazy Object Literal Initialization
    • Classes are Useful
    • Avoid Export Default
    • Limit Property Setters
    • outFile caution
    • JQuery tips
    • static constructors
    • singleton pattern
    • Function parameters
    • Build Toggles
    • Barrel
    • Create Arrays
    • Typesafe Event Emitter
  • StyleGuide
  • TypeScript Compiler Internals
    • 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

PreviousCommon ErrorsNextTesting

Last updated 5 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 interchangably.

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