-
Notifications
You must be signed in to change notification settings - Fork 122
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
Comments
it's version 17.2.0 that adds the problem, if you go back to version 17.1.1 then it's not there. |
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). |
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. |
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. |
…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.
…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
…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
Hello, Issue reproduces after updating to Angular Language Service 17.2.2. |
Hello, I can also confirm that the issue is still there for v17.2.2. But still v17.2.2 has the problem |
I can reproduce in 17.2.2 but not 17.2.1. For now I have downgraded. |
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 |
(reopening for visibility, until we can confirm that the problem is indeed fixed) |
…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
i have this problem in 17.1 though, i tried downgrading but the problem was still there. |
Still have this issue on v17.2.2. Downgrading to v17.1.1 "solved" it for now. ( |
…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
Fixed by just updating angular to latest version (in case it's not obvious to some) |
I have the issue on v17.2.2 Its still happening on ngModels |
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). |
Hello,
the error is
|
My issue still there, with latest Visual Code (
Red underlying below text Some more information, output of
By the way, downgrade to 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. |
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.
17.2.1 was a re-release of 17.1.1 so that should work.
Without anything reproducible, there's nothing actionable. Please also limit conversations to what's relevant to the issue report in the thread. |
Thanks @atscott Today I upgraded the Angular version for two of my projects. Issue disappeared after running following:
This brings my Angular version to And I also cannot reproduce issue starting from scratch. |
Another coincident finding is that. For my 2nd project, I upgrade with Not sure this adds any extra value, but happy to share here. |
@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. |
FYI seeing this issue with Angular 14 + extension v17.2.2. v17.1.1 seems to resolve as suggested. 👍🏾 |
(asking again for reproduction/logs which would be super helpful in tracking down these issues) |
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 forgot to mention this VS Code on windows. The project is private unfortunately. |
@atscott |
Thanks, that would be very helpful! |
@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: Viewing the type check block of the component did not show an attempted use of the When I updated the version to 17.2.2, the version is again identified correctly |
@atscott I compared the 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:
I get the error. |
@Cronkan Okay, yes that would be the issue. The extension is not able to find nested 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: |
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.
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. |
Great! |
oh also could you consider as well the following folder structure when fixing the issue?
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 |
This should be fixed in the 17.3.1 release |
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
🐞 bug report
Is this a regression?
Yes, the previous version in which this bug was not present was: 17.1.1Description
Since updating to version 17.2.0,
Property 'ɵunwrapWritableSignal' does not exist on type xxx/node_modules/@angular/core/index
shows up on [(ngModel)]The text was updated successfully, but these errors were encountered: