Gathering detailed insights and metrics for make-deno-edition
Gathering detailed insights and metrics for make-deno-edition
Gathering detailed insights and metrics for make-deno-edition
Gathering detailed insights and metrics for make-deno-edition
Automatically makes package.json projects (such as npm packages and node.js modules) compatible with Deno.
npm install make-deno-edition
Typescript
Module System
Min. Node Version
Node Version
NPM Version
72.7
Supply Chain
66.6
Quality
75.7
Maintenance
100
Vulnerability
100
License
TypeScript (99.28%)
JavaScript (0.72%)
Total Downloads
639,025
Last Day
7
Last Week
583
Last Month
2,964
Last Year
21,710
NOASSERTION License
43 Stars
93 Commits
2 Watchers
1 Branches
2 Contributors
Updated on Sep 27, 2024
Minified
Minified + Gzipped
Latest Version
2.3.0
Package Id
make-deno-edition@2.3.0
Unpacked Size
105.42 kB
Size
24.79 kB
File Count
24
NPM Version
10.2.3
Node Version
20.10.0
Published on
Dec 29, 2023
Cumulative downloads
Total Downloads
Last Day
-98.2%
7
Compared to previous day
Last Week
-57.3%
583
Compared to previous week
Last Month
67.6%
2,964
Compared to previous month
Last Year
-54.7%
21,710
Compared to previous year
10
Automatically makes package.json projects (such as npm packages and node.js modules) compatible with Deno.
Here is the growing list of all the packages that make-deno-edition has made compatible with Deno.
Node.js and TypeScript support unresolved paths, e.g. import thing from './file'
and import thing from './'
. Deno however, only supports resolved paths, e.g. import thing from './file.ts'
and import thing from 'https://unpkg.com/badges@^4.13.0/edition-deno/index.ts'
. This means that anything imported into Deno must be directly resolvable and must use ECMAScript Modules (ESM).
Node.js and TypeScript support package.json
files to specify dependency versions, which enables code like import dep from 'dep'
. Deno however, has no conception of package.json
, so all dependencies must be imported via a directly resolvable CDN URL, e.g. import dep from 'https://unpkg.com/dep@^1.0.0/file.ts'
.
Deno and Node.js different on their APIs. Node.js builtins can be converted to Deno's std/node
builtins, however several things such as __filename
, __dirname
require a polyfill, and other things have no direct compatibility so require different entries.
In the end, you must hope your dependencies are also compatible with Deno.
make-deno-edition is a CLI tool that takes your source edition (whichever directory contains your package's typescript source files) and creates a compatible deno edition in a edition-deno
directory.
It provides this compatibility by providing the following transformations:
bultin imports (e.g. fs
) are mapped to their corresponding deno node:*
polyfill
certain globals (e.g. __filename
and __dirname
) are mapped to their corresponding deno userland polyfilll
internal imports (any relative path to another file inside your source edition) are mapped to their typescript file, e.g. import thing from './file'
and import thing from './file.js'
becomes import thing from './file.ts
remote imports (e.g. any URL) are assumed to be compatible, as node.js doesn't support them, so it is assumed they are already deno compatible
dependency imports (e.g. any package you install into node_modules) are supported by:
If they have a deno
field in their package.json
, which will denote where to look for the deno compatible entry file, then it's direct unpkg URL will be used.
The more dependencies that make-deno-edition
is run on, then the more dependencies will automatically have a deno
entry field, and thus the more dependencies will be automatically compatible with Deno, enabling more dependents to be automatically compatible with Deno.
If they are an installed dependency, their esm.sh URL will be used.
If they are an uninstalled dependency, the npm:
prefix will be used.
make-deno-edition will also intelligently ignore compatibility for files that are not essential, such as your test and utility files, but fail if compatibility for an essential file, such as an entry file and its required modules fail
Finally, make-deno-edition will also update your package.json
file with the details for the deno entry file, as well as the deno edition metadata, such that other packages and toolchains can make use of your deno compatibility.
If you are using
boundation
to automatically generate deno compatibility for your npm package, then you can skip this step.
If you haven't already done so, add the following editions metadata to your package.json
file:
1 "editions": [ 2 { 3 "description": "TypeScript source code with Import for modules", 4 "directory": "source", 5 "entry": "index.ts", 6 "tags": [ 7 "typescript", 8 "import" 9 ], 10 "engines": false 11 } 12 ]
Make sure that the directory
is where the source files are located, in the above example, they are located in a source
directory, as it is with this repository.
Make sure that the entry
is where the entry file is located within the edition directory, in the above example, the entry is index.ts
, as it is with this repository.
If you are using
boundation
to automatically generate deno compatibility for your npm package, then you can skip this step.
Install make-deno-edition
to your development dependencies using:
1npm install --save-dev make-deno-edition
Then add a compile
npm script to your package.json
containing:
make-deno-edition --attempt
Alternatively, you can run it directly on your project via:
npx make-deno-edition --attempt
The --attempt
flag will not emit a failure exit code if the deno edition generation was not successful. If you require a deno edition to be published, remove the --attempt
flag.
If you are using
boundation
to automatically generate compatible editions (web browsers, deno, multiple node.js versions) for your npm package, then you can skip this step.
If you are using
projectz
to automatically generate yourREADME.md
content, then you can skip this step.
If a deno edition was successfully created, it will be located in the edition-deno
directory with the metadata added to the editions
array in your package.json
and a deno
entry field also added to your package.json
.
Consumers of your package who use make-deno-edition
on their own package, will now be able to use your package's deno edition to further their own deno compatibility.
You can also instruct consumers of your package to directly use your deno edition, by informing them of its presence in your README.md
file. You can use projectz
to automatically insert this information for them, or you can use the following template:
<a href="https://deno.land" title="Deno is a secure runtime for JavaScript and TypeScript, it is an alternative for Node.js"><h3>Deno</h3></a>
``` typescript
import pkg from 'https://unpkg.com/YOURPACKAGENAME@^VERSION/edition-deno/ENTRY.ts'
```
npm install --global make-deno-edition
make-deno-edition
npm install --save make-deno-edition
npx make-deno-edition
import * as pkg from ('make-deno-edition')
const pkg = require('make-deno-edition')
This package is published with the following editions:
make-deno-edition/source/index.ts
is TypeScript source code with Import for modulesmake-deno-edition
aliases make-deno-edition/edition-es2022/index.js
make-deno-edition/edition-es2022/index.js
is TypeScript compiled against ES2022 for Node.js 18 || 20 || 21 with Require for modulesmake-deno-edition/edition-es2022-esm/index.js
is TypeScript compiled against ES2022 for Node.js 18 || 20 || 21 with Import for modulesmake-deno-edition/edition-types/index.d.ts
is TypeScript compiled Types with Import for modulesDiscover the release history by heading on over to the HISTORY.md
file.
Discover how to contribute via the CONTRIBUTING.md
file.
Unless stated otherwise all works are:
and licensed under:
No vulnerabilities found.
Reason
security policy file detected
Details
Reason
no binaries found in the repo
Reason
no dangerous workflow patterns detected
Reason
license file detected
Details
Reason
4 existing vulnerabilities detected
Details
Reason
dependency not pinned by hash detected -- score normalized to 0
Details
Reason
Found 0/19 approved changesets -- score normalized to 0
Reason
0 commit(s) and 0 issue activity found in the last 90 days -- score normalized to 0
Reason
detected GitHub workflow tokens with excessive permissions
Details
Reason
no effort to earn an OpenSSF best practices badge detected
Reason
project is not fuzzed
Details
Reason
branch protection not enabled on development/release branches
Details
Reason
SAST tool is not run on all commits -- score normalized to 0
Details
Score
Last Scanned on 2025-05-05
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