Gathering detailed insights and metrics for dts-cli
Gathering detailed insights and metrics for dts-cli
Gathering detailed insights and metrics for dts-cli
Gathering detailed insights and metrics for dts-cli
@gridal/f-gridalyform
> Validation component capable of validating forms in defined languages based on given schemas. > It can create conditional fields, parse values to specific types/arrays/objects or watch for changes. > Used CLI-tool: https://github.com/weiran-zsd/dts-cli
@module-federation/third-party-dts-extractor
vite-plugin-dts
<h1 align="center">vite-plugin-dts</h1>
schema-dts
A TypeScript package with latest Schema.org Schema Typings
npm install dts-cli
Module System
Min. Node Version
Typescript Support
Node Version
NPM Version
442 Stars
856 Commits
23 Forks
4 Watching
49 Branches
1 Contributors
Updated on 19 Nov 2024
TypeScript (70.74%)
JavaScript (28.28%)
HTML (0.54%)
CSS (0.33%)
Shell (0.12%)
Cumulative downloads
Total Downloads
Last day
-16.7%
1,032
Compared to previous day
Last week
-13.6%
9,822
Compared to previous week
Last month
53.8%
39,733
Compared to previous month
Last year
29.3%
323,447
Compared to previous year
65
30
a fork of the official tsdx.
1$ npm install dts-cli -D # for npm users 2$ yarn add dts-cli -D # for yarn users 3$ pnpm install dts-cli -D # for pnpm users
Despite all the recent hype, setting up a new TypeScript (x React) library can be tough. Between Rollup, Jest, tsconfig
, Yarn resolutions, ESLint, and getting VSCode to play nicely....there is just a whole lot of stuff to do (and things to screw up). DTS is a zero-config CLI that helps you develop, test, and publish modern TypeScript packages with ease--so you can focus on your awesome new library and not waste another afternoon on the configuration.
DTS comes with the "battery-pack included" and is part of a complete TypeScript breakfast:
invariant
error codesdts test
dts lint
.babelrc.js
, jest.config.js
, .eslintrc.js
, and dts.config.js
/dts.config.ts
1npx dts-cli create mylib 2cd mylib 3yarn start
That's it. You don't need to worry about setting up TypeScript or Rollup or Jest or other plumbing. Just start editing src/index.ts
and go!
Below is a list of commands you will probably find useful:
npm start
or yarn start
Runs the project in development/watch mode. Your project will be rebuilt upon changes. DTS has a special logger for your convenience. Error messages are pretty printed and formatted for compatibility VS Code's Problems tab.
Your library will be rebuilt if you make edits.
npm run build
or yarn build
Bundles the package to the dist
folder.
The package is optimized and bundled with Rollup into multiple formats (CommonJS, UMD, and ES Module).
npm test
or yarn test
Runs your tests using Jest.
npm run lint
or yarn lint
Runs Eslint with Prettier on .ts and .tsx files.
If you want to customize eslint you can add an eslint
block to your package.json, or you can run yarn lint --write-file
and edit the generated .eslintrc.js
file.
prepare
scriptBundles and packages to the dist
folder.
Runs automatically when you run either npm publish
or yarn publish
. The prepare
script will run the equivalent of npm run build
or yarn build
. It will also be run if your module is installed as a git dependency (ie: "mymodule": "github:myuser/mymodule#some-branch"
) so it can be depended on without checking the transpiled code into git.
By default the eslint VSCode extension won't work, since it can't find the configuration file needed in order to start the eslint server. Run npm run lint -- --write-file
in order to write the config file in the correct location.
Aside from just bundling your module into different formats, DTS comes with some optimizations for your convenience. They yield objectively better code and smaller bundle sizes.
After DTS compiles your code with TypeScript, it processes your code with 3 Babel plugins:
babel-plugin-annotate-pure-calls
: Injects for #__PURE
annotations to enable treeshakingbabel-plugin-dev-expressions
: A mirror of Facebook's dev-expression Babel plugin. It reduces or eliminates development checks from production codebabel-plugin-rename-import
: Used to rewrite any lodash
importsbabel-plugin-annotate-pure-calls
+ babel-plugin-dev-expressions
work together to fully eliminate dead code (aka treeshake) development checks from your production code. Let's look at an example to see how it works.
Imagine our source code is just this:
1// ./src/index.ts 2export const sum = (a: number, b: number) => { 3 if (process.env.NODE_ENV !== 'production') { 4 console.log('Helpful dev-only error message'); 5 } 6 return a + b; 7};
dts build
will output an ES module file and 3 CommonJS files (dev, prod, and an entry file). If you want to specify a UMD build, you can do that as well. For brevity, let's examine the CommonJS output (comments added for emphasis):
1// Entry File 2// ./dist/index.js 3'use strict'; 4 5// This determines which build to use based on the `NODE_ENV` of your end user. 6if (process.env.NODE_ENV === 'production') { 7 module.exports = require('./mylib.cjs.production.js'); 8} else { 9 module.exports = require('./mylib.cjs.development.js'); 10}
1// CommonJS Development Build 2// ./dist/mylib.cjs.development.js 3'use strict'; 4 5const sum = (a, b) => { 6 { 7 console.log('Helpful dev-only error message'); 8 } 9 10 return a + b; 11}; 12 13exports.sum = sum; 14//# sourceMappingURL=mylib.cjs.development.js.map
1// CommonJS Production Build 2// ./dist/mylib.cjs.production.js 3'use strict'; 4exports.sum = (s, t) => s + t; 5//# sourceMappingURL=test-react-tsdx.cjs.production.js.map
AS you can see, DTS stripped out the development check from the production code. This allows you to safely add development-only behavior (like more useful error messages) without any production bundle size impact.
For ESM build, it's up to end-user to build environment specific build with NODE_ENV replace (done by Webpack 4 automatically).
DTS's rollup config removes getters and setters on objects so that property access has no side effects. Don't do it.
babel-plugin-dev-expressions
DTS will use babel-plugin-dev-expressions
to make the following replacements before treeshaking.
__DEV__
Replaces
1if (__DEV__) { 2 console.log('foo'); 3}
with
1if (process.env.NODE_ENV !== 'production') { 2 console.log('foo'); 3}
IMPORTANT: To use __DEV__
in TypeScript, you need to add declare var __DEV__: boolean
somewhere in your project's type path (e.g. ./types/index.d.ts
).
1// ./types/index.d.ts 2declare var __DEV__: boolean;
Note: The
dev-expression
transform does not run whenNODE_ENV
istest
. As such, if you use__DEV__
, you will need to define it as a global constant in your test environment.
invariant
Replaces
1invariant(condition, 'error message here');
with
1if (!condition) { 2 if ('production' !== process.env.NODE_ENV) { 3 invariant(false, 'error message here'); 4 } else { 5 invariant(false); 6 } 7}
Note: DTS doesn't supply an invariant
function for you, you need to import one yourself. We recommend https://github.com/alexreardon/tiny-invariant.
To extract and minify invariant
error codes in production into a static codes.json
file, specify the --extractErrors
flag in command line. For more details see Error extraction docs.
warning
Replaces
1warning(condition, 'dev warning here');
with
1if ('production' !== process.env.NODE_ENV) { 2 warning(condition, 'dev warning here'); 3}
Note: DTS doesn't supply a warning
function for you, you need to import one yourself. We recommend https://github.com/alexreardon/tiny-warning.
If you want to use a lodash function in your package, DTS will help you do it the right way so that your library does not get fat shamed on Twitter. However, before you continue, seriously consider rolling whatever function you are about to use on your own. Anyways, here is how to do it right.
First, install lodash
and lodash-es
as dependencies
1yarn add lodash lodash-es
Now install @types/lodash
to your development dependencies.
1yarn add @types/lodash --dev
Import your lodash method however you want, DTS will optimize it like so.
1// ./src/index.ts 2import kebabCase from 'lodash/kebabCase'; 3 4export const KebabLogger = (msg: string) => { 5 console.log(kebabCase(msg)); 6};
For brevity let's look at the ES module output.
1import o from"lodash-es/kebabCase";const e=e=>{console.log(o(e))};export{e as KebabLogger}; 2//# sourceMappingURL=test-react-tsdx.esm.production.js.map
DTS will rewrite your import kebabCase from 'lodash/kebabCase'
to import o from 'lodash-es/kebabCase'
. This allows your library to be treeshakable to end consumers while allowing to you to use @types/lodash
for free.
Note: DTS will also transform destructured imports. For example,
import { kebabCase } from 'lodash'
would have also been transformed to `import o from "lodash-es/kebabCase".
After running --extractErrors
, you will have a ./errors/codes.json
file with all your extracted invariant
error codes. This process scans your production code and swaps out your invariant
error message strings for a corresponding error code (just like React!). This extraction only works if your error checking/warning is done by a function called invariant
.
Note: We don't provide this function for you, it is up to you how you want it to behave. For example, you can use either tiny-invariant
or tiny-warning
, but you must then import the module as a variable called invariant
and it should have the same type signature.
β οΈDon't forget: you will need to host the decoder somewhere. Once you have a URL, look at ./errors/ErrorProd.js
and replace the reactjs.org
URL with yours.
Known issue: our
transformErrorMessages
babel plugin currently doesn't have sourcemap support, so you will see "Sourcemap is likely to be incorrect" warnings. We would love your help on this.
TODO: Simple guide to host error codes to be completed
DTS can automatically rollup TypeScript type definitions into a single index.d.ts
file via rollup-plugin-dts plugin. To enable types rollup, add --rollupTypes
flag to your build
and watch
scripts.
1 "build": "dts build --rollupTypes", 2 "start": "dts watch --rollupTypes",
rollup-plugin-dts was seen to cause issues when using json and less imports. Use with caution.
ββ οΈβ Warning:
These modifications will override the default behavior and configuration of DTS. As such they can invalidate internal guarantees and assumptions. These types of changes can break internal behavior and can be very fragile against updates. Use with discretion!
DTS uses Rollup under the hood. The defaults are solid for most packages (Formik uses the defaults!). However, if you do wish to alter the rollup configuration, you can do so by creating a file called dts.config.js
(or dts.config.ts
) at the root of your project like so:
dts.config.js
1// Not transpiled with TypeScript or Babel, so use plain Es6/Node.js! 2/** 3 * @type {import('dts-cli').DtsConfig} 4 */ 5module.exports = { 6 // This function will run for each entry/format/env combination 7 rollup(config, options) { 8 return config; // always return a config. 9 }, 10};
or
1const defineConfig = require('dts-cli').defineConfig;
2
3module.exports = defineConfig({
4 // This function will run for each entry/format/env combination
5 rollup: (config, options) => {
6 return config; // always return a config.
7 },
8});
dts.config.ts
1import { defineConfig } from 'dts-cli'; 2 3export default defineConfig({ 4 // This function will run for each entry/format/env combination 5 rollup: (config, options) => { 6 return config; // always return a config. 7 }, 8});
The options
object contains the following:
1export interface DtsOptions { 2 // path to file 3 input: string; 4 // Name of package 5 name: string; 6 // JS target 7 target: 'node' | 'browser'; 8 // Module format 9 format: 'cjs' | 'umd' | 'esm' | 'system'; 10 // Environment 11 env: 'development' | 'production'; 12 // Path to tsconfig file 13 tsconfig?: string; 14 // Is error extraction running? 15 extractErrors?: boolean; 16 // Is minifying? 17 minify?: boolean; 18 // Is this the very first rollup config (and thus should one-off metadata be extracted)? 19 writeMeta?: boolean; 20 // Only transpile, do not type check (makes compilation faster) 21 transpileOnly?: boolean; 22}
1const postcss = require('rollup-plugin-postcss'); 2const autoprefixer = require('autoprefixer'); 3const cssnano = require('cssnano'); 4 5module.exports = { 6 rollup(config, options) { 7 config.plugins.push( 8 postcss({ 9 plugins: [ 10 autoprefixer(), 11 cssnano({ 12 preset: 'default', 13 }), 14 ], 15 inject: false, 16 // only write out CSS for the first bundle (avoids pointless extra files): 17 extract: !!options.writeMeta, 18 }) 19 ); 20 return config; 21 }, 22};
You can add your own .babelrc
to the root of your project and DTS will merge it with its own Babel transforms (which are mostly for optimization), putting any new presets and plugins at the end of its list.
You can add your own jest.config.js
to the root of your project and DTS will shallow merge it with its own Jest config.
You can add your own .eslintrc.js
to the root of your project and DTS will deep merge it with its own ESLint config.
patch-package
If you still need more customizations, we recommend using patch-package
so you don't need to fork.
Keep in mind that these types of changes may be quite fragile against version updates.
DTS was originally ripped out of Formik's build tooling. DTS has several similarities to @developit/microbundle, but that is because Formik's Rollup configuration and Microbundle's internals had converged around similar plugins.
Some key differences include:
dts watch
1Description 2 Rebuilds on any change 3 4Usage 5 $ dts watch [options] 6 7Options 8 -i, --entry Entry module 9 --target Specify your target environment (default web) 10 --name Specify name exposed in UMD builds 11 --format Specify module format(s) (default cjs,esm) 12 --tsconfig Specify your custom tsconfig path (default <root-folder>/tsconfig.json) 13 --verbose Keep outdated console output in watch mode instead of clearing the screen 14 --onFirstSuccess Run a command on the first successful build 15 --onSuccess Run a command on a successful build 16 --onFailure Run a command on a failed build 17 --noClean Don't clean the dist folder 18 --transpileOnly Skip type checking 19 --rollupTypes Enable types rollup 20 -h, --help Displays this message 21 22Examples 23 $ dts watch --entry src/foo.tsx 24 $ dts watch --target node 25 $ dts watch --name Foo 26 $ dts watch --format cjs,esm,umd 27 $ dts watch --tsconfig ./tsconfig.foo.json 28 $ dts watch --noClean 29 $ dts watch --onFirstSuccess "echo The first successful build!" 30 $ dts watch --onSuccess "echo Successful build!" 31 $ dts watch --onFailure "echo The build failed!" 32 $ dts watch --transpileOnly
dts build
1Description 2 Build your project once and exit 3 4Usage 5 $ dts build [options] 6 7Options 8 -i, --entry Entry module 9 --target Specify your target environment (default web) 10 --name Specify name exposed in UMD builds 11 --format Specify module format(s) (default cjs,esm) 12 --extractErrors Opt-in to extracting invariant error codes 13 --tsconfig Specify your custom tsconfig path (default <root-folder>/tsconfig.json) 14 --transpileOnly Skip type checking 15 --rollupTypes Enable types rollup 16 -h, --help Displays this message 17 18Examples 19 $ dts build --entry src/foo.tsx 20 $ dts build --target node 21 $ dts build --name Foo 22 $ dts build --format cjs,esm,umd 23 $ dts build --extractErrors 24 $ dts build --tsconfig ./tsconfig.foo.json 25 $ dts build --transpileOnly
dts test
This runs Jest, forwarding all CLI flags to it. See https://jestjs.io for options. For example, if you would like to run in watch mode, you can run dts test --watch
. So you could set up your package.json
scripts
like:
1{ 2 "scripts": { 3 "test": "dts test", 4 "test:watch": "dts test --watch", 5 "test:coverage": "dts test --coverage" 6 } 7}
dts lint
1Description 2 Run eslint with Prettier 3 4Usage 5 $ dts lint [options] 6 7Options 8 --fix Fixes fixable errors and warnings 9 --ignore-pattern Ignore a pattern 10 --max-warnings Exits with non-zero error code if number of warnings exceed this number (default Infinity) 11 --write-file Write the config file locally 12 --report-file Write JSON report to file locally 13 -h, --help Displays this message 14 15Examples 16 $ dts lint src 17 $ dts lint src --fix 18 $ dts lint src test --ignore-pattern test/foo.ts 19 $ dts lint src test --max-warnings 10 20 $ dts lint src --write-file 21 $ dts lint src --report-file report.json
dts create
1Description 2 Create a new package with DTS 3 4Usage 5 $ dts create <pkg> [options] 6 7Options 8 --template Specify a template. Allowed choices: [basic, react, react-with-storybook] 9 --husky Should husky be added to the generated project? (default true) 10 -h, --help Displays this message 11 12Examples 13 $ dts create mypackage 14 $ dts create --template react mypackage 15 $ dts create --husky mypackage 16 $ dts create --no-husky mypackage 17 $ dts create --husky false mypackage
You can run dts watch
or dts build
with multiple entry files, for example:
1dts build \ 2 --entry ./src/index.ts \ 3 --entry ./src/foo.ts \ 4 --entry ./src/subdir/index.ts \ 5 --entry ./src/globdir/**/*.ts
When given multiple entries, dts-cli will output separate bundles for each file for each format, as well as their
declarations. Each file will be output to dist/
with the same name it has in the src/
directory. Entries in
subdirectories of src/
will be mapped to equivalently named subdirectories in dist/
.
dts-cli will also expand any globs.
Please see the Contributing Guidelines.
Thanks goes to these wonderful people (emoji key):
This project follows the all-contributors specification. Contributions of any kind welcome!
No vulnerabilities found.
No security vulnerabilities found.