This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and publish to npm yourself or setup this action to publish automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to develop, this PR will be updated.
Releases
@freshgum/typedi@1.0.0
Major Changes
40c0f8c: This is a breaking change to the core API.
The container no longer provides a default containerId parameter for the following methods:
ContainerInstance.ofChild
ContainerInstance.of
static ContainerInstance.of
In retrospect, this was a bad idea. I'll explain this further with the code below.
Ignoring the hints above, the problem with this code may not be obvious at a first glance.
While you'd assume the call to c1.ofChild() returns a child container of c1 (which
would then inherit its services), it's actually just returned an exact reference to the
default container (Container itself.)
This raises a great deal of ambiguity, as it's no longer immediately clear whether a call
to these methods does as you would initially expect.
Therefore, type-safe calls to these methods without a container ID will now raise an error at
compile-time.
The signature of these methods has been changed to require the container ID parameter.
Migrating away from this behaviour is quite simple: replace all calls to X.ofChild()
with a reference to the default container (Container).
Whilst I'm not a fan of making breaking changes to the Container, I believe this one makes
sense in the pursuit of a safer, more streamlined API -- if you experience any issues with
this, please feel free to open a GitHub issue.
Minor Changes
e70148c: The lazy function has been renamed to forwardRef.
In retrospect, the name of this function didn't clearly
describe its purpose, which is to break cyclic dependency
chains at the service initialization stage.
The renaming of this function to forwardRef more clearly
explains its function. The name was 1:1 inspired by Angular,
which contains a function that does exactly the same thing.
Note that, while lazy is deprecated, it will still be supported.
The implementation of the lazy function has been moved to
forwardRef, which is a 1:1 replacement for the former.
Patch Changes
02fe3cc: The code for virtual tokens (such as HostContainer()) has been moved into individual tokens,
as opposed to hosting logic for these tokens in ContainerInstance.
Instead, logic for these tokens is now moved into special tokens called Executable Tokens.
This yields numerous advantages, one of which being that, should a certain special token go
unused, its code can safely be removed from a bundle via dead-code elimination.
While this is mostly an internal change, the concept of Executable Tokens works quite well,
and so I'm considering making it part of the public API surface + documentation after further testing.
ad8f4f6: Dedicated entry-points have been added for web-facing builds (#184).
You're now able to use modules from contrib/ without relying on a bundler,
or importing contrib/ packages separately from /esm5/.
[!NOTE] > The changes made here do not impact current UMD / MJS entry-points.
If you're using these, you won't experience any changes.
To make use of contrib/ modules, you'll need to switch to the new builds shown above.
The new entry-points are as follows (all files are under ./build/bundles/):
import Container, { Contrib } from 'https://unpkg.dev/@freshgum/typedi/build/bundles/typedi.full.mjs';
// Let's use some modules:
const { TransientRef, ES } = Contrib;
assert(TransientRef.TransientRefHost);
The same can be done using UMD modules, like so:
<!doctype html>
<html>
<head>
<!-- ... -->
</head>
<body>
<!-- Be sure to use subresource integrity in production! ;-) -->
<script src="https://unpkg.dev/@freshgum/typedi/build/bundles/typedi.umd.full.min.js"></script>
<script>
const { Container, Contrib } = TypeDI;
// ...
</script>
</body>
</html>
[!TIP]
If you've noticed, you can actually import the Container through unpkg!
I've been wanting to implement this for a while, but life has repeatedly found itself in the way.
When spending some time on it, it was mostly a simple job: the majority of the work lied in creating
a new build step to generate a barrel file for contrib/, and then integrating Rollup with that.
If you're interested, the original code for this lies in #184. It's actually quite interesting!
This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and publish to npm yourself or setup this action to publish automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to develop, this PR will be updated.
Releases
@freshgum/typedi@1.0.0
Major Changes
40c0f8c: This is a breaking change to the core API.
The container no longer provides a default
containerId
parameter for the following methods:ContainerInstance.ofChild
ContainerInstance.of
static ContainerInstance.of
In retrospect, this was a bad idea. I'll explain this further with the code below.
Ignoring the hints above, the problem with this code may not be obvious at a first glance. While you'd assume the call to
c1.ofChild()
returns a child container ofc1
(which would then inherit its services), it's actually just returned an exact reference to the default container (Container
itself.)This raises a great deal of ambiguity, as it's no longer immediately clear whether a call to these methods does as you would initially expect.
Therefore, type-safe calls to these methods without a container ID will now raise an error at compile-time. The signature of these methods has been changed to require the container ID parameter.
Migrating away from this behaviour is quite simple: replace all calls to
X.ofChild()
with a reference to the default container (Container
).Whilst I'm not a fan of making breaking changes to the Container, I believe this one makes sense in the pursuit of a safer, more streamlined API -- if you experience any issues with this, please feel free to open a GitHub issue.
Minor Changes
e70148c: The
lazy
function has been renamed toforwardRef
.In retrospect, the name of this function didn't clearly describe its purpose, which is to break cyclic dependency chains at the service initialization stage.
The renaming of this function to
forwardRef
more clearly explains its function. The name was 1:1 inspired by Angular, which contains a function that does exactly the same thing.Note that, while
lazy
is deprecated, it will still be supported. The implementation of thelazy
function has been moved toforwardRef
, which is a 1:1 replacement for the former.Patch Changes
02fe3cc: The code for virtual tokens (such as
HostContainer()
) has been moved into individual tokens, as opposed to hosting logic for these tokens inContainerInstance
.This means that we no longer have to check for individual tokens in the container's
.get
code-path, which has historically been the case.Instead, logic for these tokens is now moved into special tokens called Executable Tokens.
This yields numerous advantages, one of which being that, should a certain special token go unused, its code can safely be removed from a bundle via dead-code elimination.
While this is mostly an internal change, the concept of Executable Tokens works quite well, and so I'm considering making it part of the public API surface + documentation after further testing.
ad8f4f6: Dedicated entry-points have been added for web-facing builds (#184). You're now able to use modules from contrib/ without relying on a bundler, or importing contrib/ packages separately from
/esm5/
.The new entry-points are as follows (all files are under
./build/bundles/
):typedi.full.min.mjs
(ES Module format.)typedi.full.mjs
typedi.umd.full.js
(UMD modules.)typedi.umd.full.min.js
You can now do the following:
The same can be done using UMD modules, like so:
I've been wanting to implement this for a while, but life has repeatedly found itself in the way. When spending some time on it, it was mostly a simple job: the majority of the work lied in creating a new build step to generate a barrel file for contrib/, and then integrating Rollup with that.
If you're interested, the original code for this lies in #184. It's actually quite interesting!