TypeScript Module Loader
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!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 tsmornode --loader tsm, then you must include the--enable-source-mapsflag manually.
Full Changelog: https://github.com/lukeed/tsm/compare/v2.2.2...v2.3.0
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.Full Changelog: https://github.com/lukeed/tsm/compare/v2.2.1...v2.2.2
esbuild dependency to its ^0.14.0 release cycle: ef3984a
Follow esbuild's Releases for thorough changelogs.
tsm --version outputdevDependency versions: cce048aFull Changelog: https://github.com/lukeed/tsm/compare/v2.1.3...v2.1.4
Support the new API for ESM loader hooks (#13, #16): b483e40
As of [email protected], 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.
Full Changelog: https://github.com/lukeed/tsm/compare/v2.1.2...v2.1.3
file:// URLs to --loader when used via child_process module.
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: https://github.com/lukeed/tsm/compare/v2.1.1...v2.1.2
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
.jsfiles, then tsm will respect that and follow your directions anyway. Your config will always execute, not just when theERR_REQUIRE_ESMerror is thrown.
options.sourcefile once per loader: 98dab33options.banner once per loader: 329ac1cFull Changelog: https://github.com/lukeed/tsm/compare/v2.1.0...v2.1.1
Support the .mts and .cts TypeScript extensions 🎉 (#3): cc7ce98
Upgraded to [email protected] 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 https://github.com/microsoft/TypeScript/issues/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: https://github.com/lukeed/tsm/compare/v2.0.0...v2.1.0