Add node types to TS project template #3212
Conversation
| break; | ||
| case FuncVersion.v2: | ||
| nodeWorkerVersion = '1'; | ||
| funcTypesVersion = '1'; | ||
| nodeTypesVersion = '10'; |
There was a problem hiding this comment.
😨
What's the support state for Functions v2?
There was a problem hiding this comment.
30 September 2022 is the listed date to end support for Node 10 (the latest version for v2). Users will still be able to run Node 10, but this is the main difference:
If you're running functions apps using an unsupported language version, you'll be required to upgrade before receiving support for the function apps.
Aka my team doesn't have to respond to incidents until user's upgrade
| @@ -2,7 +2,7 @@ | |||
| "name": "vscode-azurefunctions", | |||
| "displayName": "Azure Functions", | |||
| "description": "%azureFunctions.description%", | |||
| "version": "1.7.4-alpha.0", | |||
| "version": "1.7.4-alpha.1", | |||
There was a problem hiding this comment.
@nturinski this would be needed in package-lock.json as well.
There was a problem hiding this comment.
Damn it, I didn't want to actually pull this down and do it for him lol.
There was a problem hiding this comment.
Lol I can do it if you tell me what it's about
There was a problem hiding this comment.
Just run npm i and push up the changes to the package-lock.json. We have a new check to enforce that we bump the pre-release version on each commit to main.
For the record, I find it best to use npm version prerelease since it updates the version in all the right places without running npm i. But Nathan already updated package.json, but didn't update package-lock.json.
There was a problem hiding this comment.
Interesting - for the record I think you could automate that in the dev ops pipeline. I assume the purpose is to differentiate prerelease builds? If you chop off the ".0" from the version in git and just add it every build from main I think you'd get the same thing with less manual steps and less git churn. For example add something like this to your azure pipelines:
CURR_VER=$(node -p "require('./package.json').version")
npm version "$CURR_VER.$TODO"
Where TODO is either a build id or counter depending on your preferences
There was a problem hiding this comment.
The reason we started bumping the versions like this is if you've installed an extension from a VSIX, VS Code won't let you install (update) the same extension from a VSIX unless the extension version is different.
I think your solution would do the trick as well. I didn't know about counter, that's cool.
There was a problem hiding this comment.
Anyways I bumped the lock file for this PR. I see tests are failing, but looks like tests have been failing for a while on main so hard to tell if my PR caused that. Let me know if you want me to investigate
There was a problem hiding this comment.
The reason we started bumping the versions like this is if you've installed an extension from a VSIX, VS Code won't let you install (update) the same extension from a VSIX unless the extension version is different.
I think your solution would do the trick as well. I didn't know about counter, that's cool.
I could check again but I thought I hadn't experienced that issue. I thought the problem was that the publicly-released version of the extension had a version number higher than what we were using internally for the unified work, and VSCode kept auto-updating it.
There was a problem hiding this comment.
The reason we started bumping the versions like this is if you've installed an extension from a VSIX, VS Code won't let you install (update) the same extension from a VSIX unless the extension version is different.
I think your solution would do the trick as well. I didn't know about counter, that's cool.I could check again but I thought I hadn't experienced that issue. I thought the problem was that the publicly-released version of the extension had a version number higher than what we were using internally for the unified work, and VSCode kept auto-updating it.
I think you're right. I can't reproduce the issue I described either. For some reason I thought for sure that was an issue we had.
If the issue you described is the only reason we need these version bump checks, then we can probably remove them...
I used x range (
1.x) instead of caret (^1.0.0) to matchyo code, although I don't really care. Decided not to check local node version, just the func version. Didn't seem like Brandon cared about being super exact either.Fixes #3199