No updates until Jan 2025

[satanTime]

I guess you all noticed no active development of the library for several years.

It's going to change from January 2025.

Thanks to all who was patient and hasn't lost trust in ng-mocks.

[JPtenBerge]

Not to add to any stress, but will Angular 19 get a relatively quick version support release before that time by any chance?

[jahusa02]

Hope so too...

[evtk]

Thanks for the update @satanTime. I still use ng-mocks on daily basis as it abstracts so much of the unit test fuzz.

I came here after watching the updates for NG19 and noticing how there is getting more and more attention to implementing signals. The simple fact is that ng-mocks currently prevents me from starting to use the signal input api for instance instead of the regular Input decorator.

So really looking forward to updates on that part!

[JPtenBerge]

@evtk ng-mocks hasn't prevented me from using signal inputs. ng-mocks simply doesn't provide any help in that area.

export class MyStepComponent {
    step = input.required<Step>();

beforeEach(() => {
    TestBed.configureTestingModule({
        providers: [MockProvider(...), MockProvider(...)],
        imports: [MyStepComponent],
    });

    fixture = TestBed.createComponent(MyStepComponent);
    sut = fixture.componentInstance;
    fixture.componentRef.setInput('step', currentStep);
});

I'm not using MockRender() though, is that what you're using?

[GipHub123]

@evtk
I can confirm that input signals work with the current version of ngMocks. However, as far as I know, certain features, such as ContentChildren and ViewChild, are not yet supported.
#8895

[satanTime]

Hi all.

My main concern to release support of new versions is that my knowledge of changes in v18 and v19 is none, and I prefer to force developers to notice incompatibility with v19 and install ng-mocks with -f flag, so they understand what they do and what to expect, instead of saying that the lib works with v19.

Unfortunately, until Jan I don't have time at all due to private hassle.

[evtk]

@evtk ng-mocks hasn't prevented me from using signal inputs. ng-mocks simply doesn't provide any help in that area.

export class MyStepComponent {
    step = input.required<Step>();

beforeEach(() => {
    TestBed.configureTestingModule({
        providers: [MockProvider(...), MockProvider(...)],
        imports: [MyStepComponent],
    });

    fixture = TestBed.createComponent(MyStepComponent);
    sut = fixture.componentInstance;
    fixture.componentRef.setInput('step', currentStep);
});

I'm not using MockRender() though, is that what you're using?

Yeah definitely went for being Pro and using MockRender everywhere in my tests :|

[JPtenBerge]

@satanTime Understood, thanks for the response. And good luck on your private hassles.

[jahusa02]

Will you still be able to review PRs? If yes, I will try to at least fix the logic behind standalone :) In v19 the default flipped to true. If its possible to make this change backwards compatible I guess it wont be a new Major and so not affecting version < 19

[dmitry-stepanenko]

@jahusa02 if you will work on v19 support, you might be interested to look into my fork https://github.com/dmitry-stepanenko/ng-mocks/tree/ds/v19 . I managed to get standalone components to work well in v19 apps (it's a breaking change though). Package version with my changes can be installed directly from https://github.com/dmitry-stepanenko/ng-mocks/tree/v19-built

The only thing that I did not figure out is how to differentiate between v19 modules and old pre-compiled ones that come from 3rd party packages, because old ones should still keep "standalone: false" by default.

[GipHub123]

Hmmmh. If I'm not mistaken, 19 version fix seemed to be quite trivial 🤔

func.is-standalone.ts

return collectDeclarations(declaration)[type].standalone === true;
-->
return collectDeclarations(declaration)[type].standalone !== false;

@dmitry-stepanenko I didn’t find any version-related code either, so I assume that metadata is being used instead

In another words, change is not backward compatible.

[dmitry-stepanenko]

@GipHub123 there're a few other places where the flag should be changed in order for it to kinda work, this is done in the branch I shared above. But still if the mocked component imports an npm package that doesn't use standalone components inside, test will fail

[re-alam]

@GipHub123 @dmitry-stepanenko
I've found a simpler fix #10583 to make MockRender compatible with Angular 19. By setting the standalone property to false when generating wrapper component fixes the issue. I've also updated the isStandalone method to ensure backward compatibility. Please let me know if it works for you.

[GipHub123]

@re-alam I reviewed the code and it's seemed to be solid / it's backward compatible (I didn't test it) 👍 Version check seemed to be quite trivial / elegant 👍

[thiboot]

Good news for january !

[florestankorp]

@GipHub123 @dmitry-stepanenko I've found a simpler fix #10583 to make MockRender compatible with Angular 19. By 😎setting the standalone property to false when generating wrapper component fixes the issue. I've also updated the isStandalone method to ensure backward compatibility. Please let me know if it works for you.

Bro joined GitHub 2 weeks ago, forks 'ng-mocks', opens a PR with a fix for Angular v19. Absolute legend 😎

[Tallyb]

vitest support would be great. Happy new year!

[Martinspire]

Hmmmh. If I'm not mistaken, 19 version fix seemed to be quite trivial 🤔

func.is-standalone.ts

return collectDeclarations(declaration)[type].standalone === true; --> return collectDeclarations(declaration)[type].standalone !== false;

@dmitry-stepanenko I didn’t find any version-related code either, so I assume that metadata is being used instead

In another words, change is not backward compatible.

Couldn't there just be an iffy returning depending on what angular version is being used?

[GipHub123]

@Martinspire

Couldn't there just be an iffy returning depending on what angular version is being used?

If you review @re-alam 's code, you'll find the version check you were looking for 😉

[Martinspire]

So can we merge that? Its January after all 😄

[endlacer]

I think we have to rethink our approach to using libs from now on. Several of our large projects are blocked from being upgraded bc of this PR simply wont get merged :(

[Tallyb]

@endlacer patch-package is your friend.

[GipHub123]

@endlacer

I think we have to rethink my approach to using libs from now on. Several of our large projects are blocked from being upgraded bc of this simple PR simply wont get merged

Would it make more sense to reconsider your update policy? 😐
Why rush to update a production application immediately after a new Angular major version is released, potentially putting yourself in a difficult position?
In my opinion, it’s wiser to wait until at least the first minor release—or even later. This approach usually allows library maintainers enough time to update their code.

[satanTime]

Hi all, happy New Year!

Please, let me finish holidays :) I'll review, update, merge and release next week.

And agree regarding rushing to new versions asap. Treat it like wine - give it some time to breathe after opening.

[vinlos]

hi @satanTime

I understand it's hard to maintain an open source project alone. Do you accept pull requests for Angular major version update, so the community can contribute and speed up development?