Releases: wessberg/DI-compiler
v4.0.2
v4.0.1
v4.0.0
BREAKING CHANGES
- DI-Compiler now requires Node v.18.20.0 or newer, as it has switched to the new
--importloader mechanism andImport Attributes.
Major Changes
- feat: add TypeScript v5.6 support c502c7d
Other Changes
- Merge pull request #30 from Intellisplash/use-correct-tsconfig a6a8e11
- Merge pull request #26 from Cropster/issue-24 55bde11
- Support custom tsconfig paths 8954862
- JSX support for transform() API method f215a91
- style: run prettier d154167
- chore: move from pretty-quick to lint-staged to support Prettier v3 90bc74e
-
- chore: bump dependencies 6ece5b6
- chore: remove console.log f607138
v4.0.0-beta.1
BREAKING CHANGES
- DI-Compiler now requires Node v.18.20.0 or newer, as it has switched to the new
--importloader mechanism andImport Attributes.
Major Changes
- feat: add TypeScript v5.6 support c502c7d
- Merge pull request #30 from Intellisplash/use-correct-tsconfig a6a8e11
- Merge pull request #26 from Cropster/issue-24 55bde11
- Support custom tsconfig paths 8954862
- JSX support for transform() API method f215a91
- style: run prettier d154167
- chore: move from pretty-quick to lint-staged to support Prettier v3 90bc74e
v3.3.0
v3.2.0
v3.1.0
- feat: Add TypeScript v4.9 support
v3.0.0
New Features
DI-Compiler is now based on ESM and requires Node v14.19.0 (BREAKING CHANGE)
Now that TypeScript v4.7 is out, it has finally received great support for ES modules in a Node.js environment that aligns with how it has been implemented across Node.js and browsers.
Because of this, now is a good time to make DI-Compiler a type: "module" package. However, it still provides a CommonJS fallback. If your codebase is still based on CommonJS, you should be fine. Please know however, that di-compiler requires an environment running Node v14.19.0 or newer going forward.
Node.js loader support (BREAKING CHANGE)
In the past, you could use DI-Compiler as a CommonJS loader, like so:
node -r @wessberg/di-compiler/register
However, this had a few issues:
- It only worked in CommonJS projects
- It internally wrapped
ts-nodein a way that wasn't transparent to the user.
Now, both a CommonJS and an ESM loader is exposed, both of which are documented in the README. They don't wrap ts-node, so they can be used in conjunction with not only ts-node, but other loaders for Node.js as well that teach Node.js to handle TypeScript syntax, such as tsx or esm-loader.
To ease migration, if you want to continue using DI-Compiler as you did before where it directly wraps ts-node, a legacy loader is provided for your convenience, and here's how you can use it:
node -r @wessberg/di-compiler/ts-node-loader
Usage without a TypeScript Program
In the past years, TypeScript tooling has moved towards much faster builds in part by treating emit as purely a matter of syntax transformation, whereas it is traditionally coupled with type checking and diagnostics reporting in TypeScript. This is how tools like babel, swc, and esbuild treat TypeScript.
To allow integration with these tools, as well as to allow integration with the new Node.js loader system, DI-Compiler can now work without access to a TypeScript Program or a Type checker. When a Program isn't given, it will attempt to statically infer whether or not identifiers are instances of DIContainer, and you can help it out by passing exactly which identifiers should be treated at such. See this section in the README for more details.
TypeScript v4.7 support
DI-Compiler now supports TypeScript v4.7 and its new features.