npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

@loopback/build

v11.0.1

Published

A set of common scripts and default configurations to build LoopBack 4 or other TypeScript modules

Downloads

108,907

Readme

@loopback/build

This module contains a set of common scripts and default configurations to build LoopBack 4 or other TypeScript modules, including:

  • lb-tsc: Use tsc to compile typescript files
  • lb-eslint: Run eslint
  • lb-prettier: Run prettier
  • lb-mocha: Run mocha to execute test cases
  • lb-nyc: Run nyc

These scripts first try to locate the CLI from target project dependencies and fall back to bundled ones in @loopback/build.

Basic use

To use @loopback/build for your package:

  1. Run the following command to add @loopback/build as a dev dependency.

npm i @loopback/build --save-dev

  1. Configure your project package.json as follows:
"scripts": {
    "build": "lb-tsc",
    "build:watch": "lb-tsc --watch",
    "clean": "lb-clean",
    "lint": "npm run prettier:check && npm run eslint",
    "lint:fix": "npm run prettier:fix && npm run eslint:fix",
    "prettier:cli": "lb-prettier \"**/*.ts\" \"**/*.js\"",
    "prettier:check": "npm run prettier:cli -- -l",
    "prettier:fix": "npm run prettier:cli -- --write",
    "eslint": "lb-eslint --report-unused-disable-directives .",
    "eslint:fix": "npm run eslint -- --fix",
    "pretest": "npm run clean && npm run build",
    "test": "lb-mocha \"dist/__tests__\"",
    "posttest": "npm run lint",
    "start": "npm run build && node .",
    "prepublishOnly": "npm run test"
  },

Please remember to replace your-module-name with the name of your module.

Now you run the scripts, such as:

  • npm run build - Compile TypeScript files and copy resources (non .ts files) to outDir
  • npm test - Run all mocha tests
  • npm run lint - Run eslint and prettier on source files
  1. Override default configurations in your project
  • lb-tsc

    By default, lb-tsc searches your project's root directory for tsconfig.build.json then tsconfig.json. If neither of them exists, a tsconfig.json will be created to extend from @loopback/build/config/tsconfig.common.json.

    To customize the configuration:

    • Create tsconfig.build.json or tsconfig.json in your project's root directory

      {
        "$schema": "http://json.schemastore.org/tsconfig",
        "extends": "@loopback/build/config/tsconfig.common.json",
        "compilerOptions": {
          "outDir": "dist",
          "rootDir": "src"
        },
        "include": ["src"]
      }
    • Set options explicitly for the script

      lb-tsc -p tsconfig.json --target es2017 --outDir dist

      For more information, see https://www.typescriptlang.org/docs/handbook/compiler-options.html.

    • The following un-official compiler options are available:

      | Option | Description | | ------------------ | ------------------------------------------------------------------------------------------------- | | --copy-resources | Copy all non-typescript files from src and test to outDir, preserving their relative paths. |

    • Using ttypescript

      Stability: ⚠️Experimental⚠️

      If you would like to use ttypescript and its available plugins, you can substitute lb-tsc with lb-ttsc, or pass the option lb-tsc --use-ttypescript. If ttypescript is not installed, the default TypeScript compiler tsc will be used instead.

  1. Run builds
npm run build
  1. Run code coverage reports
  • lb-nyc

    lb-nyc is a simple wrapper for nyc.

    To customize the configuration:

    • Create .nycrc in your project's root directory

      {
        "include": ["dist"],
        "exclude": ["dist/__tests__/"],
        "extension": [".js", ".ts"],
        "reporter": ["text", "html"],
        "exclude-after-remap": false
      }
    • Update your package.json scripts:

      "precoverage": "npm test",
      "coverage": "open coverage/index.html",
      "coverage:ci": "lb-nyc report --reporter=text-lcov | coveralls",
      "test": "lb-nyc npm run mocha",
      "test:ci": "lb-nyc npm run mocha"

      coverage:ci sets up integration with Coveralls.

A note on console logs printed by tests

We consider (console) logging from tests as a bad practice, because such logs usually clutter the test output and make it difficult to distinguish legitimate error messages from the noise.

By default, lb-mocha detects when the tests and/or the application tested have printed console logs and fails the test run with the following message:

=== ATTENTION - INVALID USAGE OF CONSOLE LOGS DETECTED ===

If you need more information about behavior in the test, then the first choice should be to use a better or more descriptive error assertion. If that's not possible, then use debug statements to print additional information when explicitly requested.

A typical situation is that a test is sending an HTTP request and the server responds with an error code as expected. However, because the server is configured to log failed requests, it will print a log also for requests where the failure was expected and intentional. The solution is to configure your REST server to suppress error messages for that specific error code only. Our @loopback/testlab module is providing a helper createUnexpectedHttpErrorLogger that makes this task super easy.

Alternatively, it's also possible to disable detection of console logs by calling lb-mocha with --allow-console-logs argument.

Contributions

Tests

run npm test from the root folder.

Contributors

See all contributors.

License

MIT