npmpackage.info

Gathering detailed insights and metrics for @polkadot/dev-ts

@polkadot/dev-ts - 0.83.2 | npmpackage.info

@polkadot/dev-ts

Development configuration, scripts and and CI setup for polkadot-js projects. It acts as templates for other projects to reduce boilerplate, making everything consistent.

0.83.2

Apache-2.0

JavaScript

62.66 kB

3.9

Installations

npm install @polkadot/dev-ts

Developer Guide

BETA

Typescript

Yes

Module System

ESM

Min. Node Version

>=18

Node Version

22.12.0

NPM Version

10.9.0 Score

Supply Chain

83.2

Quality

86.9

Maintenance

100

Vulnerability

99.6

License

Pull Requests

Open

0

Total

1,126

Closed

38

Merged

1,088

Issues

Open

1

Total

31

Closed

30

Releases

Unable to fetch releases

Languages

JavaScript

TypeScript

Shell

Rust

JavaScript (73.8%)

TypeScript (24.56%)

Shell (1.58%)

Rust (0.06%)

Developer

polkadot-js

Download Statistics

Total Downloads

Last Day

Last Week

Last Month

Last Year

GitHub Statistics

Apache-2.0 License

43 Stars

2,732 Commits

20 Forks

4 Watchers

2 Branches

18 Contributors

Updated on Jun 13, 2025

Maintainers

View All 18 Contributors

Package Meta Information

Latest Version

0.83.2

Package Id

@polkadot/dev-ts@0.83.2

Unpacked Size

62.66 kB

Size

13.32 kB

File Count

NPM Version

10.9.0

Node Version

22.12.0

Published on

Jan 17, 2025

Total Downloads

Cumulative downloads

Total Downloads

NaN

Last Day

NaN

Compared to previous day

Last Week

NaN

Compared to previous week

Last Month

NaN

Compared to previous month

Last Year

NaN

Compared to previous year

Weekly Downloads

Monthly Downloads

Yearly Downloads

Dependencies

json5 tslib typescript

@polkadot/dev-ts

This is an Node TS loader, specifically written to cater for the polkadot-js needs, aka it is meant to be used inside polkadot-js projects. It doesn't aim to be a catch-all resolver, although it does cover quite a large spectrum of functionality.

It caters for -

Pass through resolution and compiling of .ts & .tsx sources
Resolution of TS aliases
Resolution of .json files (alongside aliases)
Resolution of extensionless imports (basic, best-effort)

Usage

Just add the loader via the Node.js --loader option. The API supported here is only for Node 16.12+, so ensure a new-ish LTS version is used.

node --loader @polkadot/dev-ts ...

Internally to the polkadot-js libraries, loader caching is used. This means that compiled files are store on-disk alongside the /src/ folder in /build-loader/. To enable caching behavior, the loader endpoint is changed slightly,

node --loader @polkadot/dev-ts/cached ...

This is generally the suggested default, but it is only exposed via a different loader endpoint to ensure that users explicitly opt-in and not be suprised by "random output folders" being created.

Caveats

The Node.js loader API could change in the future (as it has in the Node.js 16.12 version), so it may break or stop working on newer versions, and obviously won't work at all on older versions. As of this writing (Node.js 18.14 being the most-recent LTS), using the --loader option will print a warning.

With all that said, it is used as-is for the polkadot-js test infrastructure and currently operates without issues in that environment.

TL;DR Different configs could yield some issues.

Why

Yes, there are other options available - @babel/register, @esbuild-kit/esm-loader, @swc/register, @swc-node/loader, ts-node/esm, ...

We started off with a basic swc loader (after swapping the infrastructure from Jest & Babel), just due to the fact that (at that time, and as of writing still) the base swc loader is still a WIP against the newer loader APIs. Since we didn't want to add more dependencies (and compile differently to our internal compiler infrastructure), we adapted our own.

Since then we just swapped to using base tsc everywhere (for all builds) and may look at changing again (swc, esbuild. etc...) in the future. So effectively having a single loader, while re-inventing the wheel somewhat (since there seems to be a lot of options available) allows us to just keep the loader compiling options fully aligned with what TS -> JS output approach we take.

It meets our requirements: aligns fully with the overall configs we accross polkadot-js, compiles to ESM (no CJS used when testing/running) and has minimal dependencies that doesn't add bloat. In most cases you would probably be better off with one of the loaders/registration approaches linked in the first paragraph.

No vulnerabilities found.

10

Dangerous-Workflow

Determines if the project's GitHub Action workflows avoid dangerous patterns.

10

Binary-Artifacts

Determines if the project has generated executable (binary) artifacts in the source repository.

10

License

Determines if the project has defined a license.

7

Pinned-Dependencies

Determines if the project has declared and pinned the dependencies of its build process.

5

Code-Review

Determines if the project requires human code review before pull requests (aka merge requests) are merged.

1

Maintained

Determines if the project is "actively maintained".

0

Token-Permissions

Determines if the project's workflows follow the principle of least privilege.

0

CII-Best-Practices

Determines if the project has an OpenSSF (formerly CII) Best Practices Badge.

0

Security-Policy

Determines if the project has published a security policy.

0

Fuzzing

Determines if the project uses fuzzing.

0

SAST

Determines if the project uses static code analysis.

0

Vulnerabilities

Determines if the project has open, known unfixed vulnerabilities.

Score

3.9

/10

Last Scanned on 2025-07-07

The Open Source Security Foundation is a cross-industry collaboration to improve the security of open source software (OSS). The Scorecard provides security health metrics for open source projects.

Learn More