pnp
💡 [Feature]: Show `npm scripts` as part of Tasks view
🎯 Aim of the feature
The aim is to show and allow to run npm scripts that are specified in the package.json file of the SPFx project in the Tasks view.
The npm scripts should be shown in the same list as gulp tasks but with a different icon so there will be easier to recognize
📷 Images (if possible) with expected result
🤔 Additional remarks or comments
reference: https://github.com/pnp/vscode-viva/discussions/339#discussioncomment-12418964 https://github.com/pnp/vscode-viva/discussions/339#discussioncomment-12236090
🏗️ Follow up work (issues) after this will be done
We may create issues for the list below after we start working on this one or this will be done. We already have some ideas how we might extend this future when the initial scope of just showing npm scripts from package.json.
- [ ] group gulp tasks and npm scripts in to node/folders and refactor the list view to tree view
- [ ] add the possibility (with a '+' add button) to define your own custom command. The custom command might be either project scope (and then it should be just added to package.json as an npm script, or it may be extension scoped, in this case it should be saved in user settings for this extension and should be present always for every project. Extension scoped commands when executed should run in the default terminal in the current location of the folder.
@DonKirkham, @Youssef-El-Garmit would you like to share some feed on this issue?
@DonKirkham, @Youssef-El-Garmit would you like to share some feed on this issue?
Hello,
Thank you very much for your responsiveness! Regarding the issue of parameters, I believe the best approach would be to use a structured pattern to clearly define required and optional parameters. This would allow us to detect them automatically and prompt the user only when necessary, avoiding unnecessary requests while ensuring flexibility.
For example, we could use: • Curly braces {} for required parameters:
"build": "node build.js {env} {output}"
Here, env and output must be provided before running the script.
• Square brackets [] for optional parameters:
"start": "node app.js {mode} [debug]"
In this case, mode is required, but debug is optional.
This way, we can detect which parameters are needed and only ask for them when necessary. Let me know what you think!
Youssef's ideas are a great start but I would like to see it taken further. My idea would be to have a small wizard to prompt the user on the task display name, command line, and required/optional parameters. It would be possible to define parameter "choices" for the user to select and maybe allow custom text to be entered for a parameter. The results of the wizard could be stored in the settings for the extension, maybe with the option to the custom commands available at the workspace, user, or project level. I would think the settings would just be an array of JSON objects, since that is the most flexible option with dynamic schema. JSON also allows advanced users to create their own tasks without the wizard or export/import(copy/paste) the custom tasks.
Adding a new task would be initiated with a + icon in the Tasks section (similar to the refresh button in the Actions section) I am not sure how to build the wizard interface to collect the information as it seems like most extensions use the command palette for user interaction. For execution, the custom command display name would in the "Tasks" section of the SPFx Toolkit. Selecting the custom task would run the command if there were no parameter options for the task. If there are parameter options, the command palette could be used to collect parameters (like the "Bundle project" task does now.)
A simpler approach would be to eliminate the parameter options. The user could just create multiple tasks, each with the parameters already listed in the command. This might also be a good intermediate step until more data is collected about how much the dynamic parameter approach is needed.
As stated before, I might have some bandwidth in April to help build this. I'd love to dig into the toolkit code to see how this could be done.
@Youssef-El-Garmit, @DonKirkham thank you both for your feed and suggestions ideas. I will try to create some prototype with mockup drawings to see if we are on the right track before I open this issue up. Just to clarify I am a huge fan of small steps approach so I would not suggest to tackle all of those ideas at once. Instead my thinking was to start with adding basic support for showing and running npm scripts as part of Task view and then add follow up issues.
Also @DonKirkham just to clarify, the tasks you want to be able to specify/add, do you want them to be added as npm scripts to the currently opened project? Or rather be something you may define once and be reshared between projects? (so kept as part of extension settings as you specified)
@Youssef-El-Garmit I am not sure about the approach with braces to specify optional and required parameters. By default npm, node, tsc or any other we usually use in node scripts do not support this kind of syntax. This Would mean those commands would only work when used by SPFx Toolkit extension. But what if you share your work/project with other team members that for example use vanilla approach and do not use this extension. In this case using the npm run... to execute those command would fail for them. I wouldn't like to create features that might interact or change the currently used approaches or standards. We would need to think of some other way here. Currently I think the way we (developers) go about it is specify same commands but with different arguments/parameters and different prefix. For example
"package": "npm run clean && npm run package:ext && npm run package:webview",
"package:ext": "webpack --mode production --config ./webpack/extension.config.js --devtool hidden-source-map",
"package:webview": "webpack --mode production --config ./webpack/webview.config.js",
here I have same commands but depending what I want to build I either run npm run package:ext or npm run package:webview or just npm run package to build both
You’re absolutely right, I hadn’t considered that limitation regarding the braces syntax. The approach of using separate commands for each parameter makes a lot of sense and actually fits well with my use case. Thanks for pointing it out.
I'm all for starting simple by allowing a single command with parameters specified and just creating multiple command with different parameters, similar to how the SPFx toolkit did "Bundle Dev" and "Bundle Prod" in previous versions. (I don't remember the exact commands.) As for your question about scope, commands would be run in the current terminal. My initial use case is for spfx-fast-serve, so adding a "npm run serve" command would be added with the title "Fast serve" in the task list. By allowing the command to be saved into my User settings (Application scope), it would be available to all SPFx projects I edit and/or I could save to project settings (Windows scope) to be available to all devs on the project. I really like the idea of chaining commands together but can see where that might clutter the UI. Maybe allowing commands to be organized by folder? The individual commands could be put in a folder (collapsed) while the commands that chain the individual ones left at the top level. (I know I said keep it simple, but just made it more complex! 😆 )
As for your question about scope, commands would be run in the current terminal. My initial use case is for spfx-fast-serve, so adding a "npm run serve" command would be added with the title "Fast serve" in the task list. By allowing the command to be saved into my User settings (Application scope), it would be available to all SPFx projects I edit and/or I could save to project settings (Windows scope) to be available to all devs on the project.
Gotcha, That's a good idea 👍.
BTW for your use case, when it comes to SPFx fast serve we should rather first execute the spfx-fast-serve command which runs the SPFx fast serve cli and modifies your SPFx solution adding the proper dependencies and also the serve npm script in the package.json of the project. So I think having a npm run serve globally scoped (so between projects) might not have sense as running this command in project that were not configured for SPFx fast serve will not work and those that were configured will have this command in 'locally' in the package.json. I think the spfx-fast-serve command saved globally might have more sense in this case 🤔👍.
I really like the idea of chaining commands together but can see where that might clutter the UI. Maybe allowing commands to be organized by folder? The individual commands could be put in a folder (collapsed) while the commands that chain the individual ones left at the top level. (I know I said keep it simple, but just made it more complex! 😆 )
In this case I advice to start with a simple approach so just having a single list and as a follow up we may create an issue to refactor that to tree view grouping it for gulp tasks and for npm scripts project scope and commands extension scoped
@Youssef-El-Garmit, @DonKirkham thank you for engaging in the discussion. Based on your feed I updated the initial issue. I updated the Aim paragraph to make it a plain and simple first step of this feature. I also added a new section Follow up work (issues) after this will be done that are what we clarified (I hope 🙂) and we will create those as separate issues after the work is started/done.
Let me know what you think 🙏
lets open this up as I think the main aim of this issue (so the first step described) is quite good clarified. As for the follow up tasks/issues lets discuss this a bit more and create them once we have some more progress on this issue
@nicodecleyre I saw you assigned yourself to this one. If you are planning to implement this feature we should also align the labels by removing the help wanted and adding the work in progress
@nicodecleyre I saw you assigned yourself to this one. If you are planning to implement this feature we should also align the labels by removing the help wanted and adding the work in progress
Thx, forgot about that 😄
Merged ✅ This will be part of the new Pre-Release which most probably I will do today