what's the point of Project Files functionality?

[Spown]

If I want to use Project Files functionality - I need to either:

• manually insert V-INC every time for every file in place where old ver string was and then hit update.
  • It's not easier than just inserting the version manually. It's more hassle.
• use "RetainLine": true
  
  • I get a conveyor of version strings and that's just creates errors.

Is there a better way?

[willasm]

I'm open to any suggestions you have. The reason I added this was for my change logs in which I want to keep all the old lines. To be honest with you I am considering just removing this all together as I strongly suspect I am the only one using it that way. The way you want to use it actually makes sense. It might be better to have it search for a pattern and do a replace on match. I could use this as I have written many tampermonkey scripts myself. I could do a regex search for /^(\/\/\s+ @version\s+)(\d+\.\d+\.\d+)$/ then replace group 2 with the updated version. Ideally the regular expressions would be user defined and saved in the setting.json file. In fact I think that is what I'll do. Doing it this way, I could completely remove the need to add V-INC to any files. What do you think about this idea?

Might be best to save to the local settings.json file in the projects .vscode folder. That way the regular expressions could be defined for specific project files and only for projects where it's needed, something like Eg.

{
  "myscript": "^(\/\/\\s+ @version\\s+)(\\d+\\.\\d+\\.\\d+)$",
  "myscript": "Some other regex"
  "Some other project file name": "This files regex"
}

This was one of my first extensions and I was new to Javascript at the time. I was never really happy with this V-INC method and always thought there had to be a better way.

If you have any suggestions on anything else you would like added, let me know here, William.

[Spown]

Thank you for the reply.

Well, using .vscode folder would be kinda more aligned with the conventional way extensions do it. or dedicating settings, which also can be used both globally or per workspace in .vscode\settings.json.

The regex would be super. Only you don't need to look for the the second group. just don't capture anything that is not the version. Like this /^\/\/\s*@version\s+(\d+\.\d+\.\d+)\s*$/m - you can use it first to find the location of the entire match:

let match = /^\/\/\s*@version\s+(\d+\.\d+\.\d+)\s*$/m.exec("//@foo\n// @version      1.0.2\n// @bar");
console.log(match);

{
  0: "// @version      1.0.2",
  1: "1.0.2",
  groups: undefined,
  index: 7, // location of the whole match in the file
  input: "//@foo\n// @version      1.0.2\n// @bar",
  length: 2
}

Then you can use the same regex on the match[0] for .replace() to change the version, and then put the changed substring back at match.index location.

There are some edge cases when using the same mask on the match[0] would not work, so alternatively you can look for the position of match[1] inside of match[0] and insert the new version there, and sand the resulting substring back to file. It's also not ideal, since match[1] can occur several times in match[0] and without actual mask there is no way to tell which one should be altered. Or just do nothing if the regex does not match to anything in match[0] and alert the user he needs to fix his regex.

Also there is a question, what to actually do with the match. Put the project.json's new version there, or bump the one found in the file accordingly to the selected option? What if they differ? What if there is no project.json and the user only wants to use Project Files functionality? Or maybe there is another versioning in place, like some people use timestamps as versions, or dates. So there should be an additional setting to chose what to do. like:

{
	"Filename": "example.js",
	"FileLocation": "",
	"Enable": true,
        "Match": "^\\/\\/\\s*@version\\s+(\\d+\\.\\d+\\.\\d+)\\s*$",
	"ReplaceWith": "${PRJ_JSON_VER}", //  ${BUMP_PATCH}, ${BUMP_MINOR}, ${BUMP_MAJOR}, ${UTC_NOW}, ${YEAR2}, ${MONTHTEXTL}, ${MONTHTEXTS}, ${MONTHNUMBER}, ${DATE}, etc
	"RetainLine": false,
	"InsertBefore": "",
	"InsertAfter": ""
	"TrimTextStart": 0,
	"TrimTextEnd": 0
}

Or maybe even combine different options like "ReplaceWith": "${YEAR4}-${MONTHNUMBER}-${DATE}". Default would be syncing project.json, i.e. "${PRJ_JSON_VER}"

if "Match" option is set to anything other than "${PRJ_JSON_VER}" - it would not take the selected command's value, but the one configured and any command option would just serve as a trigger for the configured file.

For legacy reasons maybe not remove V-INC, but override it if "Match" option is defined.

I could probably help with code, if I find some time. Albeit I only tangentially familiar with vsc ext api...

[willasm]

Sorry for the late reply. I had a hard drive failure and have been without access to my programming data for a while but it is now fixed.

I really like this suggestion for the settings...

{
	"Filename": "example.js",
	"FileLocation": "",
	"Enable": true,
        "Match": "^\\/\\/\\s*@version\\s+(\\d+\\.\\d+\\.\\d+)\\s*$",
	"ReplaceWith": "${PRJ_JSON_VER}", //  ${BUMP_PATCH}, ${BUMP_MINOR}, ${BUMP_MAJOR}, ${UTC_NOW}, ${YEAR2}, ${MONTHTEXTL}, ${MONTHTEXTS}, ${MONTHNUMBER}, ${DATE}, etc
	"RetainLine": false,
	"InsertBefore": "",
	"InsertAfter": ""
	"TrimTextStart": 0,
	"TrimTextEnd": 0
}

But as you mentioned, it will take some more thought to cover all situations. I do still plan to eventually remove the V-INC requirement along with the settings RetainLine, etc, as it won't be needed with this new method. It will stay in for now but you can mark any setting in settings.json as depreciated and that will let the user know they are eventually going to be removed.

I most likely will completely re-write this extension from scratch as there is a lot of changes that need to be made. Currently every projects files to be modified has its settings stored in vscodes global storage folder which makes it very difficult for most users to access. The user currently can open these in the editor to change them but that could cause major problems if they make an error while editing them. This method alone also accounts for about half the code now.

I also want to expand the list of macros as it could more options.

I will go over the code tonight and give it some more thought.

Thanks for the suggestions, William.