[FEAT] "Confirm" GUI item for Description input

[vivaxy]

[FEAT] "Confirm" GUI item for Description input

[yi-Xu-0100]

@vivaxy @irvnriir, After I saw PR #183, I think I found an example of the settings button. 😁

I investigated the related API and other examples, and a forward button corresponding to the back button may be set later to confirm the operation. The GUI is like this:

After the PR #183 merge, I will try to implement the function of this button in my free time to solve the current issue. 😀

[yi-Xu-0100]

Thanks to @toddlerer rich implementation, I can use very little code to add a button to solve this problem. ❤

@irvnriir I complete the confirm button by workflow-vscode-conventional-commits-6025224.vsix. Try it and give your advice! 😁

@vivaxy If there is no more question about it, I will release it next friday~ 😊

[irvnriir]

@yi-Xu-0100 thats a new info . and kind of solves alot, though userconfig would still be useful for this task .

thanks .

[yi-Xu-0100]

@irvnriir conventionalCommits.promptDescription is also good for editing commit in a separate tab. See in the #189. 😁

@vivaxy The confirm button has been added! And will release on next Friday! 🎉

[yi-Xu-0100]

👋 @irvnriir Thanks for your idea!

You mean the description prompt should have selections of preset messages? In which it can be an empty selection and edit in the editor tab? 😀

If i do this using mouse, I still have to press Enter at the Description input.

By the way, I found it also, but I use the extension with full keyboard control now because I think that I always need to write the description in the editor tab. 😅

For the simple ways to set custom types, you can look into #137. 😁

[irvnriir]

@yi-Xu-0100 I mean it should have 1 selection -- "Confirm" , so that could be used to skip it using mouse . The presets: is the Types, to be defined as custom Types, or is such other .

[irvnriir]

For the simple ways to set custom types, you can look into #137. 😁

@yi-Xu-0100 seems that this doesn't work, if i'm not missing something .

Though i look into way to customize it in user-config/files (not the extension/vscode directory) .

[yi-Xu-0100]

@irvnriir Could you paste the log here? See the workflow in troubleshooting section. 😀

[irvnriir]

@yi-Xu-0100

[info] Extension Activated
[info] vscode.env.language: en
[info] last used version: 1.20.0
[info] Conventional commits started.
[info] VSCode version: 1.55.2
[info] Git version: 1.0.0
[info] VSCode Conventional Commits version: 1.20.0
[info] conventionalCommits.autoCommit: true
[info] conventionalCommits.emojiFormat: code
[info] conventionalCommits.gitmoji: false
[info] conventionalCommits.lineBreak: 
[info] conventionalCommits.promptBody: false
[info] conventionalCommits.promptFooter: false
[info] conventionalCommits.promptScopes: false
[info] conventionalCommits.scopes: 
[info] conventionalCommits.showEditor: false
[info] conventionalCommits.showNewVersionNotes: true
[info] conventionalCommits.editor.keepAfterSave: false
[info] git.enableSmartCommit: true
[info] git.smartCommitChanges: all
[info] git.postCommitCommand: none
[info] arg: undefined
[info] git.repositories: c:\Users\admin\storage\t\New folder
[info] workspaceFolders: c:\Users\admin\storage\t\New folder
[info] Load commitlint configuration successfully.
[info] commitlintRuleConfigs:
{}

[yi-Xu-0100]

@irvnriir This is a very strange situation, is your package.json saved? Does the same thing occur for restarting VS Code? Can you read the configuration directly using commitlint? Can you share the minimum reproduction repository?

[irvnriir]

@yi-Xu-0100 how would i such "use commitlint" ? its unrelated to vsc run state, other extensions and git repository .

[yi-Xu-0100]

@irvnriir I found you use the extends configuration for commitlint setting.

"commitlint": {
  "extends": [
    "@commitlint/config-conventional"
  ]
}

It needs the dependence of @commitlint/config-conventional. If you want to use the commitlint from terminal, just add a dependence of @commitlint/cli. It should read the configuration correctly. See more in cli-documents.

[info] git.repositories: c:\Users\admin\storage\t\New folder
[info] workspaceFolders: c:\Users\admin\storage\t\New folder
[info] Load commitlint configuration successfully.
[info] commitlintRuleConfigs:
{}

For now, the log shows the git.repositories, and will use the path as the load path of commitlint configuration file. It seems to find the configuration correctly but return zero rules. I don't know why. 😅

So if you do not familiar with commitlint, could you provide a simple project to reproduction this situation for me to test? 🙂

[irvnriir]

@yi-Xu-0100 i don't have Commitlint npm package installed, neither want to . so its required ? i though: you just use the compatible config name, and the config modify the extension's behavior, without depending on Commitlint .

[yi-Xu-0100]

@irvnriir
For now, If you only use the configuration about rules, you will not need any package about commitlint because the extension should load commitlint configuration about rules correctly. The extends point to a package @commitlint/config-conventional, so you need it. But it should output a warning in logs if you do not have it. 👀

I will bring a configuration option about default rules later which will not need the commitlint configuration in package.json. 😀 But be patient, I am busy recently. 🚧

And the commitlint package is used to test locally for why it does not work, which is not necessary. If you do not want to test by yourself, or you do not know how to test. Could you provide a simple project to reproduction this situation for me to test? But you know, the log shows it works well. I may not work fail with my test. So I suggest you test in your local. 😅

[irvnriir]

@yi-Xu-0100 the extension's package.json already has all the dependencies:

	"dependencies": {
		"@commitlint/cli": "^12.0.0",
		"@commitlint/config-conventional": "^12.0.0",
		"@commitlint/load": "^12.0.0",
		"@commitlint/rules": "^12.0.0",
		"@yi-xu-0100/conventional-commit-types-i18n": "1.6.0",
		"gitmojis": "^3.0.0"
	},

i doubt that the repo init settings would affect this .
New folder.zip

i would test with your help, but truly is busy too X)

[yi-Xu-0100]

@irvnriir I think I can not find the package.json in your repo. So add your configuration in your repo, not the extension path. 😅

The extension read the configuration from your repo. If you do not want to use the package.json, you also can use the commitlint.config.js in your repo.

Here is an example repo with commitlint.config.js.

New folder.zip

You do not need to edit extension files and only need to add configurations in your project. 😀

[irvnriir]

@yi-Xu-0100 this seem to work with no issues, and minimally does close this issue .

it still would be good to see ability to just select a preset, without need to further move the mouse and click . for example a setting to disable the editbox/"description" part . (so after selecting the preset/-s, the frame would close automatically)

• if autoCommit is disabled, after the preset/-s selection it would be intended to write in the Sidebar\Source Control 's editbox, which allow to edit the text before and after the preset/-s ;
• after selecting preset/-s, the Sidebar\Source Control\Commit button can be used next, if no additional text is needed .

[yi-Xu-0100]

@irvnriir I do not think the preset for the description of the commit is good. The same commit message is terrible. 😅

I can provide a configuration as conventionalCommits.promptDescription to disable the description section. But it will only work when the conventionalCommits.autoCommit setting to false or the conventionalCommits.showEditor setting to true. 😀

@vivaxy What do you think of this feature? 🧐

[vivaxy]

@irvnriir @yi-Xu-0100 I think we need more detailed information to come to a conclusion about this preset feature. It could be better if we could talk about this in another issue thread.

[irvnriir]

@yi-Xu-0100

I can provide a configuration as conventionalCommits.promptDescription to disable the description section. But it will only

this still would be an improvement .

you don't know -- what setup is better, per each project in the world .

[vivaxy]

@irvnriir That's an interesting topic. Maybe we can talk more about it in #189.
And thanks to @yi-Xu-0100 to create the issue.