@knighted/duel 1.0.6 → 1.0.7

package/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2024 KCM
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/README.md

@@ -8,13 +8,13 @@ Tool for building a Node.js [dual package](https://nodejs.org/api/packages.html#
 
 ## Features
 
-* Bidirectional ESM ↔️ CJS dual builds inferred from the package.json `type`.
-* Correctly preserves module systems for `.mts` and `.cts` file extensions.
-* Use only one package.json and tsconfig.json.
+- Bidirectional ESM ↔️ CJS dual builds inferred from the package.json `type`.
+- Correctly preserves module systems for `.mts` and `.cts` file extensions.
+- Use only one package.json and tsconfig.json.
 
 ## Requirements
 
-* Node >= 16.19.0.
+- Node >= 16.19.0.
 
 ## Example
 
@@ -24,7 +24,7 @@ First, install this package to create the `duel` executable inside your `node_mo
 user@comp ~ $ npm i @knighted/duel --save-dev
 ```
 
-Then, given a `package.json` that defines `"type": "module"` and  a `tsconfig.json` file that looks something like the following:
+Then, given a `package.json` that defines `"type": "module"` and a `tsconfig.json` file that looks something like the following:
 
 ```json
 {
@@ -67,7 +67,6 @@ If you prefer to have both builds in directories inside of your defined `outDir`
 
 Assuming an `outDir` of `dist`, running the above will create `dist/esm` and `dist/cjs` directories.
 
-
 ### Parallel builds
 
 This is experimental, as your mileage may vary based on the size of your `node_modules` directory.
@@ -84,10 +83,10 @@ You _might_ reduce your build times, but only if your project has minimal depend
 
 The available options are limited, because you should define most of them inside your project's `tsconfig.json` file.
 
-* `--project, -p` The path to the project's configuration file. Defaults to `tsconfig.json`.
-* `--pkg-dir, -k` The directory to start looking for a package.json file. Defaults to the cwd.
-* `--dirs, -d` Outputs both builds to directories inside of `outDir`. Defaults to `false`.
-* `--parallel, -l` Run the builds in parallel. Defaults to `false`.
+- `--project, -p` The path to the project's configuration file. Defaults to `tsconfig.json`.
+- `--pkg-dir, -k` The directory to start looking for a package.json file. Defaults to the cwd.
+- `--dirs, -d` Outputs both builds to directories inside of `outDir`. Defaults to `false`.
+- `--parallel, -l` Run the builds in parallel. Defaults to `false`.
 
 You can run `duel --help` to get the same info. Below is the output of that:
 
@@ -106,15 +105,15 @@ Options:
 
 These are definitely edge cases, and would only really come up if your project mixes file extensions. For example, if you have `.ts` files combined with `.mts`, and/or `.cts`. For most projects, things should just work as expected.
 
-* This is going to work best if your CJS-first project uses file extensions in _relative_ specifiers. This is completely acceptable in CJS projects, and [required in ESM projects](https://nodejs.org/api/esm.html#import-specifiers). This package makes no attempt to rewrite bare specifiers, or remap any relative specifiers to a directory index.
+- This is going to work best if your CJS-first project uses file extensions in _relative_ specifiers. This is completely acceptable in CJS projects, and [required in ESM projects](https://nodejs.org/api/esm.html#import-specifiers). This package makes no attempt to rewrite bare specifiers, or remap any relative specifiers to a directory index.
 
-* Unfortunately, TypeScript doesn't really build [dual packages](https://nodejs.org/api/packages.html#dual-commonjses-module-packages) very well in regards to preserving module system by file extension. For instance, there doesn't appear to be a way to convert an arbitrary `.ts` file into another module system, _while also preserving the module system of `.mts` and `.cts` files_, without requiring **multiple** package.json files. In my opinion, the `tsc` compiler is fundamentally broken in this regard, and at best is enforcing usage patterns it shouldn't.  This is only mentioned for transparency, `duel` will correct for this and produce files with the module system you would expect based on the file's extension, so that it works with [how Node.js determines module systems](https://nodejs.org/api/packages.html#determining-module-system).
+- Unfortunately, TypeScript doesn't really build [dual packages](https://nodejs.org/api/packages.html#dual-commonjses-module-packages) very well in regards to preserving module system by file extension. For instance, there doesn't appear to be a way to convert an arbitrary `.ts` file into another module system, _while also preserving the module system of `.mts` and `.cts` files_, without requiring **multiple** package.json files. In my opinion, the `tsc` compiler is fundamentally broken in this regard, and at best is enforcing usage patterns it shouldn't. This is only mentioned for transparency, `duel` will correct for this and produce files with the module system you would expect based on the file's extension, so that it works with [how Node.js determines module systems](https://nodejs.org/api/packages.html#determining-module-system).
 
-* If doing an `import type` across module systems, i.e. from `.mts` into `.cts`, or vice versa, you might encounter the compilation error ``error TS1452: 'resolution-mode' assertions are only supported when `moduleResolution` is `node16` or `nodenext`.``. This is a [known issue](https://github.com/microsoft/TypeScript/issues/49055) and TypeScript currently suggests installing the nightly build, i.e. `npm i typescript@next`.
+- If doing an `import type` across module systems, i.e. from `.mts` into `.cts`, or vice versa, you might encounter the compilation error ``error TS1452: 'resolution-mode' assertions are only supported when `moduleResolution` is `node16` or `nodenext`.``. This is a [known issue](https://github.com/microsoft/TypeScript/issues/49055) and TypeScript currently suggests installing the nightly build, i.e. `npm i typescript@next`.
 
-* If running `duel` with your project's package.json file open in your editor, you may temporarily see the content replaced. This is because `duel` dynamically creates a new package.json using the `type` necessary for the dual build. Your original package.json will be restored after the build completes.
+- If running `duel` with your project's package.json file open in your editor, you may temporarily see the content replaced. This is because `duel` dynamically creates a new package.json using the `type` necessary for the dual build. Your original package.json will be restored after the build completes.
 
 ## Notes
 
-As far as I can tell, `duel` is one (if not the only) way to get a correct dual package build using `tsc` while using only **one package.json** file and **one tsconfig.json** file, _and also preserving module system by file extension_. The Microsoft backed TypeScript team [keep](https://github.com/microsoft/TypeScript/issues/54593) [talking](https://github.com/microsoft/TypeScript/pull/54546) about dual build support, but their philosophy is mainly one of self-preservation, rather than collaboration. For instance, they continue to [refuse to rewrite specifiers](https://github.com/microsoft/TypeScript/issues/16577). The downside of their decisions, and the fact that `npm` does not support using alternative names for the package.json file, is that `duel` must copy your project
+As far as I can tell, `duel` is one (if not the only) way to get a correct dual package build using `tsc` with only **one package.json and tsconfig.json file**, _and also preserving module system by file extension_. Basically, how you expect things to work. The Microsoft backed TypeScript team [keep](https://github.com/microsoft/TypeScript/pull/54546) [talking](https://github.com/microsoft/TypeScript/issues/54593) about dual build support, but their philosophy is mainly one of self-preservation, rather than collaboration. For instance, they continue to [refuse to rewrite specifiers](https://github.com/microsoft/TypeScript/issues/16577). The downside of their decisions, and the fact that `npm` does not support using alternative names for the package.json file, is that `duel` must copy your project
 directory before attempting to run the builds in parallel.

package/dist/cjs/init.cjs

@@ -8,7 +8,7 @@ const node_process_1 = require("node:process");
 const node_util_1 = require("node:util");
 const node_path_1 = require("node:path");
 const promises_1 = require("node:fs/promises");
-const read_pkg_up_1 = require("read-pkg-up");
+const read_package_up_1 = require("read-package-up");
 const jsonc_parser_1 = __importDefault(require("jsonc-parser"));
 const util_js_1 = require("./util.cjs");
 const init = async (args) => {
@@ -73,7 +73,7 @@ const init = async (args) => {
             (0, util_js_1.logError)('--target-extension is deprecated. Define "type" in your package.json instead and the dual build will be inferred from that.');
             return false;
         }
-        pkg = await (0, read_pkg_up_1.readPackageUp)({ cwd: pkgDir });
+        pkg = await (0, read_package_up_1.readPackageUp)({ cwd: pkgDir });
         if (!pkg) {
             (0, util_js_1.logError)('No package.json file found.');
             return false;

package/dist/cjs/init.d.ts

@@ -1,5 +1,5 @@
 export function init(args: any): Promise<false | {
-    pkg: import("read-pkg-up", { with: { "resolution-mode": "import" } }).NormalizedReadResult;
+    pkg: import("read-package-up", { with: { "resolution-mode": "import" } }).NormalizedReadResult;
     dirs: boolean | undefined;
     parallel: boolean | undefined;
     tsconfig: any;

package/dist/esm/init.d.ts

@@ -1,5 +1,5 @@
 export function init(args: any): Promise<false | {
-    pkg: import("read-pkg-up").NormalizedReadResult;
+    pkg: import("read-package-up").NormalizedReadResult;
     dirs: boolean | undefined;
     parallel: boolean | undefined;
     tsconfig: any;

package/dist/esm/init.js

@@ -2,7 +2,7 @@ import { cwd } from 'node:process';
 import { parseArgs } from 'node:util';
 import { resolve, join, dirname } from 'node:path';
 import { stat, readFile } from 'node:fs/promises';
-import { readPackageUp } from 'read-pkg-up';
+import { readPackageUp } from 'read-package-up';
 import JSONC from 'jsonc-parser';
 import { logError, log } from './util.js';
 const init = async (args) => {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@knighted/duel",
-  "version": "1.0.6",
+  "version": "1.0.7",
   "description": "TypeScript dual packages.",
   "type": "module",
   "main": "dist",
@@ -51,7 +51,7 @@
     "url": "https://github.com/knightedcodemonkey/duel/issues"
   },
   "peerDependencies": {
-    "typescript": ">=4.0.0 || >=4.9.0-dev || >=5.2.0-dev || >=5.3.0-dev || 5.4.0-dev"
+    "typescript": ">=4.0.0 || >=4.9.0-dev || >=5.3.0-dev || 5.4.0-dev || 5.5.0-dev"
   },
   "devDependencies": {
     "@types/node": "^20.4.6",
@@ -59,7 +59,7 @@
     "eslint": "^8.45.0",
     "eslint-plugin-n": "^16.0.1",
     "prettier": "^3.2.4",
-    "typescript": "^5.4.0-dev.20231206",
+    "typescript": "^5.5.0-dev.20240228",
     "vite": "^5.0.12"
   },
   "dependencies": {
@@ -67,7 +67,7 @@
     "find-up": "^6.3.0",
     "glob": "^10.3.3",
     "jsonc-parser": "^3.2.0",
-    "read-pkg-up": "^10.0.0"
+    "read-package-up": "^11.0.0"
   },
   "prettier": {
     "arrowParens": "avoid",