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.

Sign up for GitHub

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

Jump to bottom

Add node types to TS project template #3212

Merged
merged 3 commits into from
Jun 6, 2022
Merged

Add node types to TS project template #3212

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
5e95ad8
Add node types to TS project template
ejizba Jun 6, 2022
3c4f5c3
Bump version
nturinski Jun 6, 2022
982fcd0
lock
ejizba Jun 6, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions package-lock.json
View file
Open in desktop

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

2 changes: 1 addition & 1 deletion package.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@nturinski this would be needed in package-lock.json as well.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Damn it, I didn't want to actually pull this down and do it for him lol.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lol I can do it if you tell me what it's about

Copy link
Member

@alexweininger alexweininger Jun 6, 2022 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

@bwateratmsft bwateratmsft Jun 7, 2022 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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...

"publisher": "ms-azuretools",
"icon": "resources/azure-functions.png",
"aiKey": "AIF-d9b70cd4-b9f9-4d70-929b-a071c400b217",
Expand Down
19 changes: 13 additions & 6 deletions src/commands/createNewProject/ProjectCreateStep/TypeScriptProjectCreateStep.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -42,24 +42,31 @@ export class TypeScriptProjectCreateStep extends JavaScriptProjectCreateStep {
protected getPackageJsonDevDeps(context: IProjectWizardContext): { [key: string]: string } {
// NOTE: Types package matches node worker version, not func host version
// See version matrix here: https://www.npmjs.com/package/@azure/functions
let nodeWorkerVersion: string;
let funcTypesVersion: string;
// For the node types package, we'll use the latest LTS version possible
// See version matrix here: https://docs.microsoft.com/azure/azure-functions/functions-versions?pivots=programming-language-javascript#languages
let nodeTypesVersion: string;
switch (context.version) {
case FuncVersion.v4:
nodeWorkerVersion = '3';
funcTypesVersion = '3';
nodeTypesVersion = '16';
break;
case FuncVersion.v3:
nodeWorkerVersion = '2';
funcTypesVersion = '2';
nodeTypesVersion = '14';
break;
case FuncVersion.v2:
nodeWorkerVersion = '1';
funcTypesVersion = '1';
nodeTypesVersion = '10';
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

😨

What's the support state for Functions v2?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

https://docs.microsoft.com/en-us/azure/azure-functions/language-support-policy#retirement-policy-exceptions

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

break;
default:
throw new Error(localize('typeScriptNoV1', 'TypeScript projects are not supported on Azure Functions v1.'));
}

return {
'@azure/functions': `^${nodeWorkerVersion}.0.0`,
typescript: '^4.0.0'
'@azure/functions': `^${funcTypesVersion}.0.0`,
'@types/node': `${nodeTypesVersion}.x`,
typescript: '^4.0.0',
};
}
}