I'm experimenting with refactoring a TypeScript Node library to make it isomorphic and hopefully work in Deno. I've been trying to figure out the best way to pull this off, and after finding deno2node I've decided to try making my library Deno-first and use deno2node to generate a Node-compatible version.

Unfortunately after getting the library working in Deno, deno2node errors out because the npm packages all have "npm:" in front of them which what appears to be a run of tsc after emitting files doesn't like:

npx deno2node
Loading tsconfig: 606.956ms
Basic transformations: 119.971ms
Vendoring: 0.593ms
Shimming: 0.322ms
Emitting: 1.915s
src/authentication/generateAuthenticationOptions.ts:6:8 - error TS2307: Cannot find module 
'npm:@simplewebauthn/typescript-types' or its corresponding type declarations.

6 } from 'npm:@simplewebauthn/typescript-types';
         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

...snip...

TypeScript 4.8.2
Found 71 errors.

Do you have a suggestion for how best to handle this? I was reading the section of the README about "Runtime-specific code" and wondering if I need to maintain a "deps.deno.ts" and a "deps.node.ts" to each import third-party libraries using Deno- and Node-specific naming conventions. It's not an ideal solution, though, from a developer experience perspective.

Alternatively, do you have any plans/ability to add a step to all the things deno2node does that would automatically remove "npm:" from import paths if they exist?

It would be cool to have a brief overview in the README file about the following things:

1. How does the tool even work in the first place, i.e. what does it do, and what is it build on?
2. Should I use the CLI, or a programmatic API?
3. What does the tool assert about my library (folder structure)?
4. What is the API?
5. How to use the CLI?

Some of these things are pretty obvious to answer by reading the source code for a few minutes. However, as time goes by and deno2node gets more complex, these things will become less and less clear for new users.

Problem description

Using sourceFile.fixMissingImports(); is opaque. It is not clear which dependencies are imported. Also, the imported things are not necessarily stable, they could suddenly change as I add new source files. It is not clear which symbol will be imported on clashing names. If symbols are re-exported (e.g. in mod.ts, it is not clear which location will be picked, original declaration or re-export.

Desired solution

Let users specify a file with the explicit dependencies to be used that are expected to be missing, either via a program argument or just by using a default hard-coded file name for now. Then add a import * from './<filename>.ts' as a first line to every source file.

It may be possible to explicitly import all members from that given file, and then let https://ts-morph.com/details/source-files#organizing-imports remove the unused things. This has a similar effect as fixing all missing imports, but it is explicit and there are no doubts about where things are coming from. Being explicit is a good thing, and so is reproducibility.

Hi! Thanks for your work.

I would like to propose a CLI option to choose the output extension of files and imports. In some cases, it could be useful to output cjs extension or mjs extension. This is useful to publish node package that support both esm and commonjs.

deno2node requires the code base for Deno and Node to be in a shared location, effectively interleaving the files. This leads to deps.node.ts being published, as can be observed for https://deno.land/x/grammy_router. It is preferable to only publish those files to https://deno.land/x that actually are part of the Deno source code.

Is there any way around this, maybe by moving the deps.node.ts file outside of the repository's subdirectory that gets published at deno.land?

I installed and ran from npm as instructed in the README:

username@localhost:~ $ npm i -ED deno2node
username@localhost:~ $ tree -I node_modules
.
├── package.json
├── package-lock.json
├── src
│   └── cli.ts
└── tsconfig.json

2 directories, 4 files
username@localhost:~ $ cat tsconfig.json
{
    "compilerOptions": {
        "lib": [ "esnext" ],
        "target": "esnext",
        "module": "nodenext",
        "moduleResolution": "nodenext",
        "esModuleInterop": true,
        "isolatedModules": true,

        "strict": true,
        "forceConsistentCasingInFileNames": true,

        "outDir": "build/",
        "sourceMap": true,

        "skipLibCheck": true
    },

    "include": [
        "src/**/*.ts"
    ]
}
username@localhost:~ $ npx deno2node
Loading tsconfig: 251.637ms
Basic transformations: 4.139s
Emitting: 1.175s

<--- Last few GCs --->

[18928:00000234B24D7000]    43832 ms: Scavenge (interleaved) 4053.1 (4131.2) -> 4053.1 (4132.2) MB, pooled: 0 MB, 12.51 / 0.00 ms  (average mu = 0.138, current mu = 0.089) allocation failure;
[18928:00000234B24D7000]    44207 ms: Scavenge (interleaved) 4054.1 (4132.2) -> 4054.1 (4155.2) MB, pooled: 0 MB, 374.72 / 0.00 ms  (average mu = 0.138, current mu = 0.089) allocation failure;


<--- JS stacktrace --->

FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
----- Native stack trace -----

 1: 00007FF6736BDA2B node::SetCppgcReference+15611
 2: 00007FF67362AFE4 DSA_meth_get_flags+86548
 3: 00007FF67428E351 v8::Isolate::ReportExternalAllocationLimitReached+65
 4: 00007FF67427AF76 v8::Function::Experimental_IsNopFunction+2918
 5: 00007FF6740C4DA0 v8::internal::StrongRootAllocatorBase::StrongRootAllocatorBase+31760
 6: 00007FF6740C1DAD v8::internal::StrongRootAllocatorBase::StrongRootAllocatorBase+19485
 7: 00007FF6740D7613 v8::Isolate::GetHeapProfiler+7267
 8: 00007FF6740D7EAA v8::Isolate::GetHeapProfiler+9466
 9: 00007FF6740E8A57 v8::Isolate::GetHeapProfiler+77991
10: 00007FF673DA5AEB v8::internal::Version::GetString+435643
11: 00007FF61432D9D0

cli.ts was obtained from here.

Running on Windows 11 x64 with 32GB of RAM, in case it matters.

Problem

When using web workers, one needs to use

/// <reference no-default-lib="true" />
/// <reference lib="deno.worker" />

to make the code compile on Deno.

However, when this is transformed to Node, there is no way to add a built-in library. Hence, the following error is thrown:

src/worker.ts:2:21 - error TS2726: Cannot find lib definition for 'deno.worker'.

2 /// <reference lib="deno.worker" />
                      ~~~~~~~~~~~

TypeScript 4.9.4
Found 1 errors.

Possible Solutions

1. Always remove /// <reference lib="deno.worker" /> from source files.
2. Allow "shimming" built-in libs, so we could create a file deno.worker with the necessary type definitions

Useful Links

• Blocked PQ: grammyjs/runner#10
• TS docs on /// directives for built-in libs: https://www.typescriptlang.org/docs/handbook/triple-slash-directives.html#-reference-lib-

Currently, the tool adds shims to files that are specific to Node.

The point of shims is to make Deno code run on Node. However, in platform-specific files, this does not make sense, because the code doesn't even run on Deno.

This behaviour is confusing, as grammyjs/grammY#80 (comment) shows.

Heya. Thanks for this awesome tool.

I am seeing an error when importing deno2node

Warning Implicitly using latest version (0.178.0) for https://deno.land/std/node/path.tsiB (8/12)
error: Module not found "https://deno.land/std/node/path.ts".
    at https://deno.land/x/[email protected]/src/context.ts:1:18

Looks to be an implicit import is expecting an export that is no longer there in the latest version.

Steps to reproduce:

deno run https://deno.land/x/[email protected]/src/context.ts

Looks like the functionality has been replicated on Deno's path https://deno.land/[email protected]/path/mod.ts, so could use that instead.

is possible deno2node and esm.sh or similar
in some way for dev frontend project vue or svelte using deno ? and node to build/serve deno2node output

It would be cool if we could run d2n from a URL in a project that does not contain TS config yet—mostly because the project is in Deno already, which does not require such configuration files.

My suggested solution would be to test via URL if the supplied TypeScript configuration file path is a URL, and if so, to fetch the file contents from it.

I would love deno2node to behave exactly like a tsc that is Deno-aware. I see this as the main advantage over dnt—instead of having some magic black box that somehow tries to do everything, it would be awesome to do just one thing, and do it really well: compiling Deno code for Node.

That way, we could use our existing Node workflows that are based around tsc, and use deno2node as a drop-in replacement once we move to Deno. As a result, all existing infra and Node tooling will keep on working. I cannot imagine how dnt is going to solve denoland/dnt#60 in the foreseeable future, but deno2node already integrates seamlessly with Node workflows.

At the same time, it enables us to write Deno code most of the time. We can use all their tooling, hosting, docs, infra, and all other advantages. On the Node side, in contrast to dnt, we still remain in control of our own configs and setup. In a way, deno2node brings the best of both worlds, because we can target both platforms natively, and use the familiar tooling of both ecosystems.

Some points that would be amazing to see are the following.

• deno2node --init creates a clean project from scratch which targets both Deno and Node.
• deno2node runs without a file path to tsconfig.json, and it behaves like tsc would do without config file.
• deno2node supports those compiler options that make sense from https://www.typescriptlang.org/docs/handbook/compiler-options.html#compiler-options

Readme suggestions

1. The --unstable flag is needed in the usage section to run deno2node
2. "create corresponding deps.node.ts." could be renamed to "and copy the contents of the deno.deps.ts file to a new node.deps.ts file" - it isn't entirely understandable that the node.deps.ts file needs to be the same (or does it?)
3. If your project doesnt have deno globals, you wouldnt pass in a tsconfig.json arg, yet the docs tell you to regardless of any scenario. Also, you have to pass one in, which should be optional (as in some projects, they might not use the deno namespace)

Suggestions

4. deno2node also tries transpiling certain files you dont want it to, such as test files, there shoudl be an ignore option
5. A nice example of what a shim.node.ts should look like would be nice, i was scratching my head for a while until i decided to check your source code to see if you had one and how that looked
6. lack of test files is worrying
7. Why was a tsconfig.json chosen to specify the shim? surely that file shouldn't be responsible for holding these configurations (and goes against the schema right?)
8. Be nice to restrict perms even more, eg the docs specify --allow-write=src --allow-net=deno.land

Tried to run the CLI using Deno on the project itself.

1. Clone this repo, and cd into it.
2. Run:

$ deno run --unstable --allow-read --allow-write https://raw.githubusercontent.com/wojpawlik/deno2node/v0.2.0/src/cli.ts src/tsconfig.json 
Download https://cdn.esm.sh/v41/[email protected]/deno/validate-npm-package-name.js
error: Import 'https://cdn.esm.sh/v41/[email protected]/deno/validate-npm-package-name.js' failed: 404 Not Found
    at https://esm.sh/[email protected]:2:0

Same error occurs when running npm i in the top level directory of this project.

It seems like deno2node strips comments and JSDoc. It therefore removes the documentation of the library. Is this intended?

Tried with

deno run --unstable --allow-read --allow-write \
  https://raw.githubusercontent.com/wojpawlik/deno2node/v0.4.0/src/cli.ts tsconfig.json

for grammY runner.