v2.3.0

Features

• Bump esbuild to ^15.16.0 version.
  Previously using the 14.x release cycle.
  This 15.x range includes features such as:
  * Yarn Plug'N'Play (PnP) support
  * Improved Yarn Workspaces support
  * New supported options (accessible within tsm config)
  * Support for TypeScript 4.9 satisfies operator (#42)
  * Improved imports subpath resolution (#31)
  * Adds deno as a valid target value
  * & more.. see esbuild changelog!

Patches

• Correctly resolve non-.js file when requiring or importing the would-be .js virtual path (#33):
  TypeScript allows (and expects) you to write import("./App.js") in your source, even though only App.tsx or App.jsx exists on disk. There are many other extension aliases like this, all of which are now supported:

  "*.js"  // <-- [".js", ".ts", ".tsx", ".jsx"]
  "*.mjs" // <-- [".mjs", ".mts"]
  "*.cjs" // <-- [".cjs", ".cts"]
  "*.jsx" // <-- [".jsx", ".tsx"]

• Fix dynamic imports within CommonJS files (#27)
  Previously, tsm left dynamic imports alone, relying on native behavior. However, this meant that the node -r tsm <file> usage might encounter code like import("./Post.tsx") that would throw an error because native import() cannot deal with the .tsx file type. This release now covers this use case, allowing CommonJS/--require users to dynamically import any non-.js file... tsm will transform it correctly, as configured.

• Improve source map support for tsm <file> CLI usage (#32):
  When running tsm directly, the --enable-source-maps flag is enabled for native Node.js sourcemap support. This means that any errors / stack traces will correctly map to the .ts source locations!

  Note: If running node -r tsm or node --loader tsm, then you must include the --enable-source-maps flag manually.

---

Full Changelog: v2.2.2...v2.3.0

v2.2.2

Patches

• Add support for Node.js v18.6.0+ (#36, #37): 82c0e90
  Node 18.6 now requires shortCircuit: true in return values. This is a breaking change within the Node 18.x release cycle, but this (I suppose) is permissible since ESM hooks are still in Stability 1: Experimental stage.
  
  Thank you @antongolub for the fix~!

---

Full Changelog: v2.2.1...v2.2.2

v2.2.0

Features

• Upgrade esbuild dependency to its ^0.14.0 release cycle: ef3984a
  Follow esbuild's Releases for thorough changelogs.

v2.1.4

Patches

• Correct the tsm --version output

Chores

• Bump devDependency versions: cce048a

---

Full Changelog: v2.1.3...v2.1.4

v2.1.3

Patches

• Support the new API for ESM loader hooks (#13, #16): b483e40

  As of Node@16.12.0, ESM loader hooks received an API update. This release adheres to the new design while also continuing support for the previous (now deprecated) API design.

  tsm will continue to support both API designs until sufficient time has passed that it's safe to assume users are no longer using (or should be using) previous/non-LTS Node versions that carry the old design. Dropping support for the old ESM loader hooks design will likely warrant a future 3.0.0 release.

Chores

• (docs) Update "shell script" wording: 73b8c77
  Thank you @niieani~!

---

Full Changelog: v2.1.2...v2.1.3

v2.1.2

Patches

• (bin): Support global usage on Windows: 67600a7
  Apparently, on Windows, you need to pass file:// URLs to --loader when used via child_process module.

Chores

• (docs): Include usage instructions/example for using tsm as a bash shebang: 83896bc

  #!/usr/bin/env tsm
  import { greet } from './hello';
  
  let [name] = process.argv.slice(2);
  greet(name || 'world');
  //=> Hello, world!

---

Full Changelog: v2.1.1...v2.1.2

v2.1.1

Patches

• Ensure Windows support (#9): acb1071

• Allow usage through global installation: fbbb29f

• Allow require() of ".js" files with ESM content (#7, #8): 822f0ba
  This handles the ERR_REQUIRE_ESM error thrown when you require ESM ".js" file(s).

  Previously, tsm didn't handle the case where you could require a foo.js file that contained ESM syntax. Even though this combination is/should be invalid, tsm has to be able to rewrite the file(s) as necessary in the event there's a series or combination of tools that produce this scenario.

  For example, you could be writing tests in TypeScript & those tests import third-party code that's written in ESM within .js files. When executing those tests with a require hook – for example uvu -r tsm tests – then the TypeScript would be converted into CommonJS, making require() calls to the third-party ".js" file, which still contains ESM. This would fail.

  This is implemented in a way such that node -r tsm does nothing to .js files by default. It will only retry a .js file if the ERR_REQUIRE_ESM error was thrown. In fact, if any loader (regardless of extension) attempts to execute but throws the ERR_REQUIRE_ESM error, then the file is retried w/ the same options, but forcing format: cjs the second time around.

  Note: If you add custom configuration for .js files, then tsm will respect that and follow your directions anyway. Your config will always execute, not just when the ERR_REQUIRE_ESM error is thrown.

Chores

• Add typescript + "type: module" tests: 1368d98
• (require): Determine options.sourcefile once per loader: 98dab33
• (require): Determine options.banner once per loader: 329ac1c

---

Full Changelog: v2.1.0...v2.1.1

v2.1.0

Features

• Support the .mts and .cts TypeScript extensions 🎉 (#3): cc7ce98

  Upgraded to esbuild@0.13.4 which includes full support for these extensions. This upgrade allows tsm to safely support & add .mts and .cts to its default extensions map.

• Allow JavaScript extensions for TypeScript imports (#2, #1): c935537

  If you have a foo.ts file, this allows you to import it as foo.js from another file. This is useful for TypeScript projects that are not using a bundler, where every input is mapped to its own output file. In this this scenario, and when producing ESM output, you need to include the .js extension in your import statements so that the output file(s) resolve to fully-qualified URLs.

  Note: This is a long-awaited TypeScript feature & there's now official movement. Please see microsoft/TypeScript#16577 or this nice summary thread.

  Example Usage

  Assume this project structure:

  demo
  ├── aaa.ts
  ├── bbb.cts
  ├── ccc.mts
  └── main.ts
  

  And the main.ts file includes the following:

   import aaa from './aaa.js';
   // => loads the "aaa.ts" file
  
   import bbb from './bbb.cjs';
   // => loads the "bbb.cts" file
  
   import ccc from './ccc.mjs';
   // => loads the "ccc.mts" file

---

Full Changelog: v2.0.0...v2.1.0