Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Property 'ɵunwrapWritableSignal' does not exist on type #2001

Closed
albancho opened this issue Feb 13, 2024 · 38 comments
Closed

Property 'ɵunwrapWritableSignal' does not exist on type #2001

albancho opened this issue Feb 13, 2024 · 38 comments
Labels

Comments

@albancho
Copy link

🐞 bug report

Is this a regression?

Yes, the previous version in which this bug was not present was: 17.1.1

Description

Since updating to version 17.2.0,
Property 'ɵunwrapWritableSignal' does not exist on type xxx/node_modules/@angular/core/index shows up on [(ngModel)]

@albancho albancho added the bug label Feb 13, 2024
@arnotixe
Copy link

extension
Just searched through my code, and it squiggles all 132 occurances of [(ngModel)] no matter the component type
image

And also squiggles the prop in my home grown components using that same kind of bi-directional binding:
image

export class LoginselectorComponent implements OnInit {
  @Input() altselect = false;
  @Output() altselectChange = new EventEmitter<boolean>();
  …

app still builds and deploys though 🥳 so I guess it's an editor nuisance only

@gcoadour
Copy link

Please check that your angular language service has been updateed. The latest release (2/12/2024) fixes this.

it's version 17.2.0 that adds the problem, if you go back to version 17.1.1 then it's not there.
You can see here that several users are affected: https://stackoverflow.com/questions/77986204/property-%c9%b5unwrapwritablesignal-does-not-exist-on-type/77987961#77987961

@JeanMeche
Copy link
Member

JeanMeche commented Feb 13, 2024

Yes my bad, it was the other way around.

Yes the current work around is to downgrade the angular language service extension (or to update to 17.2 when it will be available).

@AndrewKushnir
Copy link
Collaborator

Thanks for reporting the issue. The problem is that a newer version of Angular compiler (used within the Language Service) relied on some symbols that were added in an RC version of 17.2.0.

We'll work on improving version detection to prevent such issues in the future. Meanwhile we plan to rollback a version change in the Language Service and publish it as 17.2.1 shortly.

@AndrewKushnir
Copy link
Collaborator

Quick update: Language Service VSCode extension with a previous version of the compiler is now released as v17.2.1 (release info). Note: it may take a couple hours for a new version to become available for download at the marketplace.

I'm closing this ticket as completed for now, please reopen if the problem still exists after updating to v17.2.1.

crisbeto added a commit to crisbeto/angular that referenced this issue Feb 13, 2024
…lder than 17.2

In order to allow both signals and non-signals in two-way bindings, we have to pass the expression through `ɵunwrapWritableSignal`. The problem is that the language service uses a bundled compiler that is fairly new, but it may be compiling an older version of Angular that doesn't expose `ɵunwrapWritableSignal` (see angular/vscode-ng-language-service#2001).

These changes add a `_angularCoreVersion` flag to the compiler which the language service can use to pass the parsed Angular version to the compiler which can then decide whether to emit the function.
AndrewKushnir pushed a commit to angular/angular that referenced this issue Feb 13, 2024
…lder than 17.2 (#54423)

In order to allow both signals and non-signals in two-way bindings, we have to pass the expression through `ɵunwrapWritableSignal`. The problem is that the language service uses a bundled compiler that is fairly new, but it may be compiling an older version of Angular that doesn't expose `ɵunwrapWritableSignal` (see angular/vscode-ng-language-service#2001).

These changes add a `_angularCoreVersion` flag to the compiler which the language service can use to pass the parsed Angular version to the compiler which can then decide whether to emit the function.

PR Close #54423
AndrewKushnir pushed a commit to angular/angular that referenced this issue Feb 13, 2024
…lder than 17.2 (#54423)

In order to allow both signals and non-signals in two-way bindings, we have to pass the expression through `ɵunwrapWritableSignal`. The problem is that the language service uses a bundled compiler that is fairly new, but it may be compiling an older version of Angular that doesn't expose `ɵunwrapWritableSignal` (see angular/vscode-ng-language-service#2001).

These changes add a `_angularCoreVersion` flag to the compiler which the language service can use to pass the parsed Angular version to the compiler which can then decide whether to emit the function.

PR Close #54423
@andreidiaconescu
Copy link

Hello,

Issue reproduces after updating to Angular Language Service 17.2.2.
At version 17.2.1 the issue was not reproducing.

@MaximilianMohr
Copy link

Hello,

I can also confirm that the issue is still there for v17.2.2.
I skipped v17.2.1 because I had already downgraded to v17.1.1 so I cannot say that 17.2.1 would have fixed the issue for me.

But still v17.2.2 has the problem

@joukevandermaas
Copy link

I can reproduce in 17.2.2 but not 17.2.1. For now I have downgraded.

@alxhub
Copy link
Member

alxhub commented Feb 15, 2024

If you're able to create a self-contained repro and share it (likely as a Github repo) that would be incredibly helpful in tracking down this issue. Also, uploading your language service log (Command Palette > Angular: Open Angular Server log) would also help (please check if it contains data you don't want to share - all we really need is any line that mentions _angularCoreVersion).

@alxhub alxhub reopened this Feb 15, 2024
@alxhub
Copy link
Member

alxhub commented Feb 15, 2024

(reopening for visibility, until we can confirm that the problem is indeed fixed)

atscott pushed a commit to atscott/angular that referenced this issue Feb 16, 2024
…lder than 17.2 (angular#54423)

In order to allow both signals and non-signals in two-way bindings, we have to pass the expression through `ɵunwrapWritableSignal`. The problem is that the language service uses a bundled compiler that is fairly new, but it may be compiling an older version of Angular that doesn't expose `ɵunwrapWritableSignal` (see angular/vscode-ng-language-service#2001).

These changes add a `_angularCoreVersion` flag to the compiler which the language service can use to pass the parsed Angular version to the compiler which can then decide whether to emit the function.

PR Close angular#54423
@felikshetalia
Copy link

i have this problem in 17.1 though, i tried downgrading but the problem was still there.

@jonasduever
Copy link

Still have this issue on v17.2.2.

Downgrading to v17.1.1 "solved" it for now.

(@angular/core: 17.0.4 - will try if upgrading the @angular/* dependencies solves it later this week.)

vladboisa pushed a commit to vladboisa/angular that referenced this issue Feb 20, 2024
…lder than 17.2 (angular#54423)

In order to allow both signals and non-signals in two-way bindings, we have to pass the expression through `ɵunwrapWritableSignal`. The problem is that the language service uses a bundled compiler that is fairly new, but it may be compiling an older version of Angular that doesn't expose `ɵunwrapWritableSignal` (see angular/vscode-ng-language-service#2001).

These changes add a `_angularCoreVersion` flag to the compiler which the language service can use to pass the parsed Angular version to the compiler which can then decide whether to emit the function.

PR Close angular#54423
@jpike88
Copy link

jpike88 commented Feb 21, 2024

Fixed by just updating angular to latest version (in case it's not obvious to some)

@OnurEAkgul
Copy link

I have the issue on v17.2.2 Its still happening on ngModels

@atscott
Copy link
Collaborator

atscott commented Feb 22, 2024

Could someone who is still experiencing this issue please provide a reproduction?

This has not been reproducible since 17.2.2 and will be closed soon without the ability to confirm it's an issue with the extension rather than a setup issue (failing to reload VSCode, having multiple versions of Angular in node modules, etc).

@andreidiaconescu
Copy link

Hello,
as mentioned in a previous comment, for me, this issue does reproduce on the latest version:
17.2.2 but not on version 17.2.1
in some of the templates where i have
[(ngModel)]="eventEndDate"
for example:

            <input
              matInput
              [matDatepicker]="eventDownloadStartDate"
              [max]="maxDateValidation"
              name="eventStartDate"
              [(ngModel)]="eventStartDate"
            />

the error is

Property 'ɵunwrapWritableSignal' does not exist on type 'typeof import("/mnt/otherLinuxPartition/var/www/kickstart/frontend/node_modules/@angular/core/index")'.ngtsc(2339)
general-settings.component.ts(14, 45): Error occurs in the template of component GeneralSettingsComponent.
public (property) GeneralSettingsComponent.eventStartDate: Date

@dopsun
Copy link

dopsun commented Feb 22, 2024

My issue still there, with latest Visual Code (1.86.2) and Angular Language Service (v17.2.2).

<input type="text" class="form-control" id="orgCode" name="orgCode" required [(ngModel)]="viewModel.orgCode">

Red underlying below text [(ngModel)]="viewModel.orgCode", and while hover, it reports the issue.

Some more information, output of ng version:

Angular CLI: 17.0.3
Node: 20.10.0
Package Manager: npm 10.2.3
OS: darwin arm64
Angular: 17.0.4
... animations, common, compiler, compiler-cli, core, forms
... localize, platform-browser, platform-browser-dynamic, router

Package                         Version
---------------------------------------------------------
@angular-devkit/architect       0.1700.3
@angular-devkit/build-angular   17.0.3
@angular-devkit/core            17.0.3
@angular-devkit/schematics      17.0.3
@angular/cdk                    17.0.1
@angular/cli                    17.0.3
@schematics/angular             17.0.3
rxjs                            7.8.1
typescript                      5.2.2
zone.js                         0.14.2

By the way, downgrade to 17.2.1, issue disappeared for my case.

Also somehow recently, I feel (no scientific data to support), I restarted my Visual Code more often than before, due to randomly click-to-navigate feature (in component html) does not work for Angular project and restart it work again.

@atscott
Copy link
Collaborator

atscott commented Feb 22, 2024

My issue still there, with latest Visual Code (1.86.2) and Angular Language Service (v17.2.2).
...
Some more information, output of ng version:

I'm afraid just listing versions is not enough information at this time. I cannot reproduce the issue with the same versions you've listed. Please provide a github repo that can be used to reproduce the issue.

By the way, downgrade to 17.2.1, issue disappeared for my case.

17.2.1 was a re-release of 17.1.1 so that should work.

Also somehow recently, I feel (no scientific data to support), I restarted my Visual Code more often than before, due to randomly click-to-navigate feature (in component html) does not work for Angular project and restart it work again.

Without anything reproducible, there's nothing actionable. Please also limit conversations to what's relevant to the issue report in the thread.

@atscott atscott added needs repro and removed bug labels Feb 22, 2024
@dopsun
Copy link

dopsun commented Feb 23, 2024

Thanks @atscott

Today I upgraded the Angular version for two of my projects. Issue disappeared after running following:

ng update @angular/core@17 @angular/cli@17

This brings my Angular version to 17.2.2. I have tested with two existing projects separately, both work after upgrade.

And I also cannot reproduce issue starting from scratch.

@dopsun
Copy link

dopsun commented Feb 23, 2024

Another coincident finding is that. For my 2nd project, I upgrade with ng update, and then git rollback package.json and package-lock.json files only, it still works without any issue.

Not sure this adds any extra value, but happy to share here.

@Licen-it
Copy link

@atscott I can reproduce the issue locally and the only difference from what mentioned by others above is that i'm using angular v14. I'll see if I can setup something easy on github.
image

@janaka
Copy link

janaka commented Feb 28, 2024

FYI seeing this issue with Angular 14 + extension v17.2.2. v17.1.1 seems to resolve as suggested. 👍🏾

@alxhub
Copy link
Member

alxhub commented Feb 28, 2024

If you're able to create a self-contained repro and share it (likely as a Github repo) that would be incredibly helpful in tracking down this issue. Also, uploading your language service log (Command Palette > Angular: Open Angular Server log) would also help (please check if it contains data you don't want to share - all we really need is any line that mentions _angularCoreVersion).

(asking again for reproduction/logs which would be super helpful in tracking down these issues)

@atscott
Copy link
Collaborator

atscott commented Feb 28, 2024

@janaka @Licen-it I was also not able to reproduce this issue in 14.0.0 or 14.2.0. We've mentioned a few times that we will need a project that the issue can be reproduced with, as we haven't been able to with any of the listed versions in previous comments.

@Licen-it
Copy link

@janaka @Licen-it I was also not able to reproduce this issue in 14.0.0 or 14.2.0. We've mentioned a few times that we will need a project that the issue can be reproduced with, as we haven't been able to with any of the listed versions in previous comments.

I tried to setup a new mini-project using one of the examples in the angular tutorial, but I wasn't able to reproduce it, so unless it's involving some other dependencies i have in the project, the only difference between the 2 was that with the project where i can reproduce the issue i use yarn, while in the other i used npm. I don't think this difference would impact the angular extension in any way, but worth to share anyway.
I'll try to see if i can get logs as @alxhub mentioned

@janaka
Copy link

janaka commented Feb 29, 2024

@janaka @Licen-it I was also not able to reproduce this issue in 14.0.0 or 14.2.0. We've mentioned a few times that we will need a project that the issue can be reproduced with, as we haven't been able to with any of the listed versions in previous comments.

I forgot to mention this VS Code on windows.

The project is private unfortunately.

@Cronkan
Copy link

Cronkan commented Feb 29, 2024

@atscott
Here is a repo where i've reproduced it: https://github.com/Cronkan/language-server-error
Seems to be version specific, we run 17.1.2 atm in our projects, generating a new project with ^17.2.3 does not seem to have the same problem.

@alxhub
Copy link
Member

alxhub commented Feb 29, 2024

I tried to setup a new mini-project using one of the examples in the angular tutorial, but I wasn't able to reproduce it, so unless it's involving some other dependencies i have in the project, the only difference between the 2 was that with the project where i can reproduce the issue i use yarn, while in the other i used npm. I don't think this difference would impact the angular extension in any way, but worth to share anyway. I'll try to see if i can get logs as @alxhub mentioned

Thanks, that would be very helpful!

@atscott
Copy link
Collaborator

atscott commented Feb 29, 2024

@Cronkan Hmm, I was not seeing the issue in your reproduction either. Some more information would be helpful. Here are some things to look at:

Looking at the output channel and the angular server logs ("Angular: open Angular server log" in command palette), the extension should have identified that you're using 17.1.2:
Screenshot 2024-02-29 at 9 37 41 AM

Viewing the type check block of the component did not show an attempted use of the ɵunwrapWritableSignal function:
Screenshot 2024-02-29 at 9 41 59 AM

When I updated the version to 17.2.2, the version is again identified correctly
Screenshot 2024-02-29 at 9 43 39 AM
Screenshot 2024-02-29 at 9 38 40 AM

@frozenfrank
Copy link

I was experiencing this issue on Angular Language Service v17.2.2, but then after reading this whole thread, I restarted VScode and the issue stopped happening. It's resolved for me now!

image

@Cronkan
Copy link

Cronkan commented Feb 29, 2024

@atscott
Yeah sorry, seems like it used the wrong angular version after i downgraded in package.json. Restarting the language-server made it work. :(
Thing is that the Using Angular version xx.x.x doesn't show at the top in the projects that has the error (the one i provided works):
image

I compared the tsconfig.ts etc. and angular.json and changed some stuff that wasn't the same but no dice.
Also turned on logging and server messages and looks the same. So the culprit seems to be Using Angular version xx.x.x but that doesn't show up in the logs.

Update: I found that when i open the web project directly i dont get the error. But when opening the project folder containing multiple projects in the structure like:

./src/Project.Web
./src/Project.WebAPI

I get the error.
Here is a new repo for the error: https://github.com/Cronkan/language-server-error-folder
Open the root so you can see \src\lang-error\src etc.

@atscott
Copy link
Collaborator

atscott commented Feb 29, 2024

Update: I found that when i open the web project directly i dont get the error. But when opening the project folder containing multiple projects in the structure like:

@Cronkan Okay, yes that would be the issue. The extension is not able to find nested node_modules folders when trying to determine the project versions at startup. In addition, this determination is made once on startup and uses the same options for all projects in the workspace.

As a temporary workaround, you can add your angular project folder to the workspace so it is one of the workspace roots. Using your reproduction, here the extension identifies the version correctly:

Screenshot 2024-02-29 at 12 27 58 PM
Screenshot 2024-02-29 at 12 28 16 PM

@Licen-it
Copy link

Licen-it commented Feb 29, 2024

Update: I found that when i open the web project directly i dont get the error. But when opening the project folder containing multiple projects in the structure like:

@Cronkan Okay, yes that would be the issue. The extension is not able to find nested node_modules folders when trying to determine the project versions at startup. In addition, this determination is made once on startup and uses the same options for all projects in the workspace.

As a temporary workaround, you can add your angular project folder to the workspace so it is one of the workspace roots. Using your reproduction, here the extension identifies the version correctly:

Screenshot 2024-02-29 at 12 27 58 PM Screenshot 2024-02-29 at 12 28 16 PM

Ok then that would explain why i wasn't able to reproduce with the example project i tried, but i can in my work project.
In my project structure the root level is not the angular project for the UI...that is inside a nested folder. I configured vscode angular service to point at the angular.json level instead looking for angular at the top folder.
My structure is something like:

Root
  |-- backend folder
  |-- ui folder
          |-- node_modules

Is it something fixable in the extension?

@atscott
Copy link
Collaborator

atscott commented Feb 29, 2024

Is it something fixable in the extension?

Yes. I can't commit to a timeframe but this should absolutely be fixable in the extension and we will be investigating what can be done here.

@Cronkan
Copy link

Cronkan commented Mar 1, 2024

Update: I found that when i open the web project directly i dont get the error. But when opening the project folder containing multiple projects in the structure like:

@Cronkan Okay, yes that would be the issue. The extension is not able to find nested node_modules folders when trying to determine the project versions at startup. In addition, this determination is made once on startup and uses the same options for all projects in the workspace.

As a temporary workaround, you can add your angular project folder to the workspace so it is one of the workspace roots. Using your reproduction, here the extension identifies the version correctly:

Screenshot 2024-02-29 at 12 27 58 PM Screenshot 2024-02-29 at 12 28 16 PM

Great!
The issue seems also only affect banana-in-the-box [(var)] which had no problems in previous versions.
If it's hard to fix, could an alternative be to provide a setting for overriding angularCoreVersion that we can place in our ./.vscode/settings.json for the time beeing? i.e "angular.coreVersion": "17.1.2"

@Licen-it
Copy link

Licen-it commented Mar 1, 2024

Is it something fixable in the extension?

Yes. I can't commit to a timeframe but this should absolutely be fixable in the extension and we will be investigating what can be done here.

oh also could you consider as well the following folder structure when fixing the issue?

root
  |-- ui folder 1
  |        |-- node_modules
  |-- ui folder 2
  |        |-- node_modules
  |-- backend folder

where the two UI folders would have different package.json and angular configuration? In my use case they have same angular version so no big deal, but i believe a solution where you can in case set which one would be the main folder to setup the angular version for the project would be a nice to have

@atscott
Copy link
Collaborator

atscott commented Mar 20, 2024

This should be fixed in the 17.3.1 release

@atscott atscott closed this as completed Mar 20, 2024
@angular-automatic-lock-bot
Copy link

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

This action has been performed automatically by a bot.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Apr 20, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests