refactor: move package files to top level

[JamieMagee]

This PR includes:

• Moving package.json, package-lock.json, .eslintrc.json, and task.json to the root of the repository
• Renaming buildAndReleaseTask to src
• Adding the build task as an npm script
• Adding build to the GitHub Action
• Outputting the compiled JavaScript to the dist folder, instead of alongside the TypeScript source

Signed-off-by: Jamie Magee [email protected]

[JamieMagee]

@gattjoe this is ready for review

[gattjoe]

@JamieMagee I'm going to have to stare at this a bit to determine the implications. I've only ever set it up according to the documentation; however, the documentation doesn't say whether or not what you suggest is not possible, its fairly ambiguous.

I'll take a look this week at it.

[JamieMagee]

I understand where you are coming from, but the layout suggested in your link is specifically for the tutorial:

The home directory of a build or release task extension should look like the following example after you complete the steps in this tutorial

The important parts are the files property in vss-extension.json

azure-devops-demo/vss-extension.json

Lines 23 to 30 in c1d53b8

	"files": [
	{
	"path": "buildAndReleaseTask"
	},
	{
	"path": "images", "addressable": true
	}
	],

and execution in task.json

azure-devops-demo/buildAndReleaseTask/task.json

Lines 34 to 39 in c1d53b8

	"execution": {
	"Node16": {
	"target": "index.js"
	}
	}
	}

The directory structure and hierarchy is pretty free-form, but the standard that defines it is called Open Packaging Conventions¹. There's some more documentation on it here. .vsix files are zip files so you can open them up and check the contents.

Footnotes

1. https://en.wikipedia.org/wiki/Open_Packaging_Conventions ↩

[JamieMagee]

I updated the target paths for vss-extension.json and task.json. I think I'll tackle #25 after this, as the .vsix is 27MB with node_modules but only ~100KB if it's bundled 😬

[gattjoe]

@JamieMagee thanks for the link to the vsix package documentation, reading now.

[gattjoe]

hmm this is failing tests. I think I have to change a few things in index.ts since it relies on task.json. They used to be in the same directory, so it wasn't an issue before. I have to think about what the execution environment is going to look like from an agent perspective.

Overall, the biggest problem I have is that I have to literally publish a "BETA" version of the extension privately to KNOW if it will work in the wild. I have a different version of the agent published privately, and I'm happy to set up a pipeline in my ADO organization against a fork so you can iterate with it. If you have your own ADO organization, I can share the extension with you to install.