-
Notifications
You must be signed in to change notification settings - Fork 604
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
[rush] VSCode Extension #3162
base: main
Are you sure you want to change the base?
[rush] VSCode Extension #3162
Conversation
773045f
to
15afb42
Compare
Questions 2022/3/3
|
Note: PR #3337 has renamed our GitHub |
vsce/vscode-extension/package.json
Outdated
"dependencies": { | ||
"@microsoft/rush-lib": "workspace:*", | ||
"@rushstack/node-core-library": "workspace:*", | ||
"@rushstack/rush-sdk": "workspace:*", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The trick to running webpack on @rushstack/rush-sdk
is the @rushstack/webpack-preserve-dynamic-require-plugin
, FYI.
3c343eb
to
0bf58a3
Compare
37b58fe
to
7c7ef34
Compare
7c7ef34
to
7142099
Compare
Thanks to the hints from David's PR: #3651 I updated the building and packing process to rushstack vscode extension Now, in extension development, it will be always try to load Also, this extension can be correctly packed to a "visx" format file, which means it's ready to be published to VSCode marketplace! |
"outFiles": [ | ||
"${workspaceFolder}/vscode-extensions/rush-vscode-extension/dist/**/*.js" | ||
], | ||
"preLaunchTask": "npm: build:watch - vscode-extensions/rush-vscode-extension" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do heft commands work instead as the preLaunchTask?
@@ -154,6 +154,8 @@ These GitHub repositories provide supplementary resources for Rush Stack: | |||
| [/repo-scripts/generate-api-docs](./repo-scripts/generate-api-docs/) | Used to generate API docs for the rushstack.io website | | |||
| [/repo-scripts/repo-toolbox](./repo-scripts/repo-toolbox/) | Used to execute various operations specific to this repo | | |||
| [/rush-plugins/rush-litewatch-plugin](./rush-plugins/rush-litewatch-plugin/) | An experimental alternative approach for multi-project watch mode | | |||
| [/vscode-extensions/rush-vscode-command-webview](./vscode-extensions/rush-vscode-command-webview/) | Webview to run rush command in VSCode Extension | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should use rushstack
instead of rush
as the language here. This extension will be a collection of all the relevant rushstack
tools. In the future we wouldn't want an extension for rush, heft, etc.
|
||
useEffect(() => { | ||
// const defaultValues: FieldValues = defaultValuesRef.current; | ||
console.log('rest', defaultValues); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Remove console.log
}, [form]); | ||
const { control, watch, reset } = form; | ||
|
||
// const defaultValuesRef: MutableRefObject<FieldValues> = useRef<FieldValues>({}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Remove commented out code
}, | ||
devtool: production ? undefined : 'source-map', | ||
optimization: { | ||
runtimeChunk: false, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are we just attempting to achieve one output bundle with this config? Looking for some rationale behind these config changes.
new HtmlWebpackPlugin({ | ||
template: 'public/index.html' | ||
}), | ||
new BundleAnalyzerPlugin({ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's only run this during production in the same way we only generate sourcemaps for production. BundleAnalyzer is known for slowing down builds considerably.
"license": "MIT", | ||
"author": "Cheng Liu<[email protected]>", | ||
"publisher": "Microsoft", | ||
"main": "./dist/extension.js", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We use /lib/ as our convention no?
"@vscode/test-electron": "^1.6.2", | ||
"eslint": "~8.7.0", | ||
"glob": "~7.0.5", | ||
"mocha": "^9.1.3", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know the default scaffolding for vscode extensions for yeoman provides mocha, but shouldn't we absolutely use jest and the infrastructure we have in place for testing?
const date = now.getDate(); | ||
const hour = now.getHours(); | ||
const min = now.getMinutes(); | ||
const version = `${year}_${month}_${date}_${hour}_${min}`; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will this be our versioning schema for the extension package. Is this the best practice and what does vscode do with their community extensions for versioning?
// your extension is activated the very first time the command is executed | ||
export async function activate(context: vscode.ExtensionContext): Promise<void> { | ||
context.subscriptions.push( | ||
vscode.commands.registerCommand('rushstack.selectWorkspace', async () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If there is no inscope state needs, we should simply extract the entire command into a separate module. It should be crystal clear where each of our commands live and we should separate each of them into their own modules. And example of this looks like:
Summary
RushStack VSCode Extention
Details
Fixes #3157
How to develop in local
a
[Extension Development Host]
window should popup if everything works fine. Open a rush project nowHow to pack a production version and install it locally
Run the following command, a vsix format file called "rushstack-0.0.0.vsix" will be generated.
Run
code --install-extension rushstack-0.0.0.vsix
to install the prod version of rushstack vscode extensionRun
code --uninstall-extension rushstack
to uninstall itRecipe:
code --uninstall-extension rushstack || true && code --install-extension rushstack-0.0.0.vsix