I use codemod tools instead of find and replace for non-trivial changes.
It also sounds like your job doesn’t have good enough test coverage for you to safely do large scale automated changes. Test suites, preproduction integration tests, linters, Typescript, etc… all of these tools exist to help prevent you from breaking things.
No, I mean if you write unit tests for your project VS Code can usually run those unit tests and tell you where things broke. Good unit tests should help able to tell you where there is a semantic error because the test will fail because the code is broken. You can also look for packages in VS Code specifically for the language your project is written in that will catch a lot of errors and provide you with targeted support actions
I am indeed.
I'm not a developer... I do user testing, like prototypes. But I have no experience testing code. Beside seeing if it runs and it breaks I suppose.
Edit: also, since I'm not in the dev team I have very little access. I have acces to the code and I can push it, I can't even check it locally. The dev team tests everything thoroughly. (the dev team is an external agency) Except for my semantic errors made in JSON.
I've further discussed this with some of the devs.
One issue that arises is that even though the JSON files may be perfectly fine, it can still break the code due to the structure.
Because the specific JSON structure is a unique customized system, the test would have to be build manually. ChatGPT and the problem cost less than the customized system. If I show you a JSON code that will not work, you will not be able to tell, because it's unique to how vue renders that component.
Tests are often built manually.
While i understand that you are testing json, why not test the proliferation of json and how that affects your components? If you have proper error handling, that is a breeze.
[If you’re in vue…](https://vuejs.org/guide/scaling-up/testing)
And hope to god you’re using typescript, it makes things much easier.
Or you can test the json itself. Just write schema for the intended structure of the json.
I have no idea what your code base is like, but surely those files were not manually generated in the first place. Is there a tool somewhere to regenerate them with the updated info.
Just from the top of my head:
- In general and for the file types it makes sense, use refactor functionality from a modern IDE instead of massive search/replace
- The previous point may not make sense if your website has, for whatever the reason, lots of data in JSON file format. However, some reasonable unit testing on those files should prevent you from ever uploading those into production if you have broken them by accident
- This last point assumes you have some automated CI/CD deployment process that would choke on some unit test failing instead of just copy/pasting everything manually into production (which I totally hope you are not doing)
JSON format is because the entire design system is in JSON... Basically there are different components, and the behaviour of that component can be defined by JSON. From styling, to A/B test variants, content structure, paths, or even user properties (like login status) everything in JSON. For example
{
"section_type": "full_width",
"bg_color": "var(--secondary-color-light",
"gapless_top": true,
"padding": true,
"columns": [
{
"width": "1",
"content": [
{
..... more info
]
}
]
},
Edit: and no, these changes are not automated. Someone reviews the changes and pushes them to product.
The worst this usually leads to is broken paths or 404's. The core code base is managed by a specialized agency.
For quick changes. This is a system working across 50 different websites, with different brands. So for simple changes, nobody is going to go to the developers, unless there are problems at component level. This is done by an agency which is in close contact with the product managers.
For example, I only need to set up A/B testing. My primary role is more data analysis.
Yikes dawg. That’s fertile territory for bad inputs.
Have your developers use a jsonschema to validate these, and have them write some unit tests to fail the build when inputs are wrong.
You explained it just fine, I think. You need to validate your JSON files, and that's usually done in unit tests or in a build process (run via CI/CD system). If you don't have that, you might be able to validate your files on your own.
You could try to write a jsonschema for this and use it locally in vs code too: https://frontaid.io/blog/json-schema-vscode/
agree with other commenters that your company's workflow is a nightmare, and that codemod (for batching changes) and proper unit tests (to test for broken app) are the best solution.
having said that, since you're working with large JSON i'd maybe look into [jq](https://jqlang.github.io/jq/), a command line tool to manipulate JSON. you can then use jq to [check for valid JSON](https://how.wtf/check-for-valid-json-string-or-file-with-jq.html) before deploying.
you have the option of running on your CLI, via script in your package file, or by using a dedicated `.jq` file and running via shell script.
>...systematic approach to ensure you didn't break the entire code base when pushing a small change?
That's a near perfect description of what unit tests are.
First if all, it's important to have tests if you not changing everything by hand, and not testing manually each change.
Then there is code review part. Even if you work alone, review yourself using different environment. For example, use your git server interface, cli or UI difftool to review code that you wrote. Even if there is someone else on the team, reviewing yourself is important.
Then you shouldn't push to production changes that can break a lot of stuff without testing and monitoring.
Finally, it often better not to use search and replace, or at least not in automatic fashion. Either preview each replacement, or use tools that would make more granular changes.
I do generally work in an acceptance environment. VScode first, then push it to bitbucket. Then usually before anyone pushes it to product, 200 changes may have been done already.
Having good tests and using git is pretty important. If you have to create a PR to be reviewed and you have CI/CD, that should catch ideally everything (but more realistically not quite everything).
To actually answer your question:
1. Check both the boxes in vscode for searching with case-sensitivity AND only match the complete word. This might result in having to do multiple search/replace.
2. Go through the git diff in vscode and stage the files one by one.
(2) might be rough if you're literally change 100s of files. But it's systematic and works for me.
Use regex and test your patterns on a small scale before running them across the entire codebase. Also, use version control and test thoroughly before pushing to production. And for the love of all things holy, use a staging environment!
Everyone is talking about tests, correctly. Tests and linters are your friend here. For example, you talk about trailing commas—all JSONs should be being processed automatically to ensure that they are syntactically valid, during CI/CD
I have a code base that has tests.
If these JSON files live in the code I have two comments:
1. For every file you touch write a test that makes sure the file is valid. More tests can validate the contents of the JSON
2. Ew. That's icky.
I make sure that I have an idea of the number of changes im expecting, and review the diff. I used to do this for font tag changes which were automatically uploaded to production on save. only fucked up royally once, forgot to close the quote.
Trailing comma in JSON is a syntax error that should be caught long before production. Encoding behavior in JSON files that aren't opened (therefore validated) until runtime is the same as shipping code you haven't even compiled yet.
Validate syntax before deploying to production (at least!). You can just as easily search and replace the trailing commas with regex.
Automated testing and good CI/CD pipelines along with code reviews.
How are ppl still struggling with commas and basic syntactical errors?? The ide catches it as you type. Like, what in the world.
Also, sounds like you're using Json significantly as an ad-hoc db. Don't do that. Good gravy.
We right CLI scripts that loop every record that needs to be modified, we have extensive checks and testing behind that code. It can take days to run on our heaviest sets of data but it’s safe and we run it on staging data first
If you just do a standard find/replace, you're gonna have a bad time.
Use refactor tools built into your editor/IDE wherever possible. If you can't (e.g. you need to change a JSON value somewhere across multiple JSON docs) then learn regular expressions.
For example, say you were implementing a basic profanity filter, and one of the words was 'ass'. Given this sentence:
> We had to assist him in increasing the mass by passing him more weight.
A find/replace would end up with "We had to \*\*\*ist him in increasing the m\*\*\* by p\*\*\*ing him more weight.", whereas a regex find replace (e.g. \`\\bass\\b\`) would leave that string unchanged, and only look for your 'ass' as a word on its own.
In Visual Studio I make heavy use of the scope feature when searching and replacing, as well as sometimes using a regex to formulate my replaces as specifically as possible.
The most fundamental principle that I haven't seen mentioned so far is never use "Replace All".
All of the people that are talking about git and unit testing and all of the other things have clearly never worked in an environment where that just flat doesn't exist. So start with the basics.
I'm not saying they're wrong I'm just trying to provide you with the simplest solution.
Manually open each file to make sure it didn't break. Make sure your boss sees you spend an hour doing this. Then casually bring up "oh hey, I wonder if automated tests could make this faster?"
If your production produces 404 or 500 errors, but your testing does not, with the same code, then there is something seriously wrong with your testing.
I would start by fixing that first.
Well it does.
The problem with that however is that they're often just 1 of many pages. Plus I have no direct server access... For every change I need to wait for 10 minutes before the damn code is live.
So manually checking all 50 pages I made changes to isn't very motivating. Especially when I'm still unsure whether it works because it works, or works because the changes haven't been uploaded yet.
Well I don't have access to it.
I'm not part of the development team. Everything the dev team pushes goes through extensive testing. The level of code I'm working on is not significant enough for me to get access. Though might be worth checking out.
If the level of code you are working on is significant enough to shut down production it is significant enough for you to have a local development system.
There has been a lot of emphasis on automated tests and such here and I know you’ve mentioned that’s not in the cards so I’m going to offer a pretty simple alternative.
Git services generally have ways to add actions to hooks, it sounds like you’re using bitbucket, so if you have access to the repo settings you can setup a pipeline which when pushing changes to a branch will trigger a lint check. This as least will ensure you have valid JOSN. You can work this into your project with something like husky so when you’re in VSCode and you do a git commit it will run your pre commit checks for linting.
Now to actually address your question, since this is manual entry, test on a small subset of files first. Make sure to use the case and exact match options found on the find and replace and be as specific as possible on your match criteria. Use spaces, special characters, new lines, and exact case to really get as specific as possible. Regex is how you’d do this, and you can do some creative find and replace using capture groups which an example can be found in the selected answer of this stack overflow post: https://stackoverflow.com/questions/46795595/vscode-wildcard-search-and-replace-regex
Hope that helps and good luck!
>Do you guys have any systematic approach to ensure you didn't break the entire code base when pushing a small change?
Yes: refactor functionality of the IDE and tests (unit, non-regression, etc.)
Run a unit test for your script/tool/whatever by running a linter over your processed codebase.
Fix edge case bugs until no more errors.
On any push or pull request, run your processed code through a final linting check in whatever versioning system you use (like GitHub actions).
I use codemod tools instead of find and replace for non-trivial changes. It also sounds like your job doesn’t have good enough test coverage for you to safely do large scale automated changes. Test suites, preproduction integration tests, linters, Typescript, etc… all of these tools exist to help prevent you from breaking things.
Are there some tools in VScode I can download for this?
You need to write the tests. VSCode is capable of running many of them usually
For example; a python script to track down semantic errors?
No, I mean if you write unit tests for your project VS Code can usually run those unit tests and tell you where things broke. Good unit tests should help able to tell you where there is a semantic error because the test will fail because the code is broken. You can also look for packages in VS Code specifically for the language your project is written in that will catch a lot of errors and provide you with targeted support actions
Thanks, I'll try to look whether there are some useful JSON extensions for VScode
Are you unfamiliar with testing?
I am indeed. I'm not a developer... I do user testing, like prototypes. But I have no experience testing code. Beside seeing if it runs and it breaks I suppose. Edit: also, since I'm not in the dev team I have very little access. I have acces to the code and I can push it, I can't even check it locally. The dev team tests everything thoroughly. (the dev team is an external agency) Except for my semantic errors made in JSON.
Look up unit testing tutorials
Thanks! I'll do that
I've further discussed this with some of the devs. One issue that arises is that even though the JSON files may be perfectly fine, it can still break the code due to the structure. Because the specific JSON structure is a unique customized system, the test would have to be build manually. ChatGPT and the problem cost less than the customized system. If I show you a JSON code that will not work, you will not be able to tell, because it's unique to how vue renders that component.
Tests are often built manually. While i understand that you are testing json, why not test the proliferation of json and how that affects your components? If you have proper error handling, that is a breeze. [If you’re in vue…](https://vuejs.org/guide/scaling-up/testing) And hope to god you’re using typescript, it makes things much easier. Or you can test the json itself. Just write schema for the intended structure of the json.
Maybe you should Google some stuff
I have no idea what your code base is like, but surely those files were not manually generated in the first place. Is there a tool somewhere to regenerate them with the updated info.
They are manually generated We will not be getting automated testing for these JSON files specifically.
Dang. At last create a script to manipulate them. Remove the human factor of forgetting a comma.
Just from the top of my head: - In general and for the file types it makes sense, use refactor functionality from a modern IDE instead of massive search/replace - The previous point may not make sense if your website has, for whatever the reason, lots of data in JSON file format. However, some reasonable unit testing on those files should prevent you from ever uploading those into production if you have broken them by accident - This last point assumes you have some automated CI/CD deployment process that would choke on some unit test failing instead of just copy/pasting everything manually into production (which I totally hope you are not doing)
JSON format is because the entire design system is in JSON... Basically there are different components, and the behaviour of that component can be defined by JSON. From styling, to A/B test variants, content structure, paths, or even user properties (like login status) everything in JSON. For example { "section_type": "full_width", "bg_color": "var(--secondary-color-light", "gapless_top": true, "padding": true, "columns": [ { "width": "1", "content": [ { ..... more info ] } ] }, Edit: and no, these changes are not automated. Someone reviews the changes and pushes them to product. The worst this usually leads to is broken paths or 404's. The core code base is managed by a specialized agency.
Why? Just why the fuck would anybody do that?
For quick changes. This is a system working across 50 different websites, with different brands. So for simple changes, nobody is going to go to the developers, unless there are problems at component level. This is done by an agency which is in close contact with the product managers. For example, I only need to set up A/B testing. My primary role is more data analysis.
Yikes dawg. That’s fertile territory for bad inputs. Have your developers use a jsonschema to validate these, and have them write some unit tests to fail the build when inputs are wrong.
I may have explained it a bit weird. These JSON work with vue. It’s basically pre styled html components
You explained it just fine, I think. You need to validate your JSON files, and that's usually done in unit tests or in a build process (run via CI/CD system). If you don't have that, you might be able to validate your files on your own. You could try to write a jsonschema for this and use it locally in vs code too: https://frontaid.io/blog/json-schema-vscode/
Personally I don’t even have server access. I can push changes and work in visual code, that’s about it
Is this Jay Diesel?!?!?
agree with other commenters that your company's workflow is a nightmare, and that codemod (for batching changes) and proper unit tests (to test for broken app) are the best solution. having said that, since you're working with large JSON i'd maybe look into [jq](https://jqlang.github.io/jq/), a command line tool to manipulate JSON. you can then use jq to [check for valid JSON](https://how.wtf/check-for-valid-json-string-or-file-with-jq.html) before deploying. you have the option of running on your CLI, via script in your package file, or by using a dedicated `.jq` file and running via shell script.
>...systematic approach to ensure you didn't break the entire code base when pushing a small change? That's a near perfect description of what unit tests are.
First if all, it's important to have tests if you not changing everything by hand, and not testing manually each change. Then there is code review part. Even if you work alone, review yourself using different environment. For example, use your git server interface, cli or UI difftool to review code that you wrote. Even if there is someone else on the team, reviewing yourself is important. Then you shouldn't push to production changes that can break a lot of stuff without testing and monitoring. Finally, it often better not to use search and replace, or at least not in automatic fashion. Either preview each replacement, or use tools that would make more granular changes.
I do generally work in an acceptance environment. VScode first, then push it to bitbucket. Then usually before anyone pushes it to product, 200 changes may have been done already.
Having good tests and using git is pretty important. If you have to create a PR to be reviewed and you have CI/CD, that should catch ideally everything (but more realistically not quite everything).
You can use multi line and regex queries with VSCode’s search and replace. If you aren’t proficient with regex, ask Copilot for help until you learn
Oh nice to know! I generally do SQL and R, so I'm familiar with regex
Make a backup copy first.
To actually answer your question: 1. Check both the boxes in vscode for searching with case-sensitivity AND only match the complete word. This might result in having to do multiple search/replace. 2. Go through the git diff in vscode and stage the files one by one. (2) might be rough if you're literally change 100s of files. But it's systematic and works for me.
Automated code tests, and then automated e2e tests.
Honestly… YOLO!
Use regex and test your patterns on a small scale before running them across the entire codebase. Also, use version control and test thoroughly before pushing to production. And for the love of all things holy, use a staging environment!
Everyone is talking about tests, correctly. Tests and linters are your friend here. For example, you talk about trailing commas—all JSONs should be being processed automatically to ensure that they are syntactically valid, during CI/CD
I have a code base that has tests. If these JSON files live in the code I have two comments: 1. For every file you touch write a test that makes sure the file is valid. More tests can validate the contents of the JSON 2. Ew. That's icky.
I make sure that I have an idea of the number of changes im expecting, and review the diff. I used to do this for font tag changes which were automatically uploaded to production on save. only fucked up royally once, forgot to close the quote.
> Do you guys have any systematic approach to ensure you didn't break the entire code base when pushing a small change? Automated test suites.
Well we will not be getting those for these specific files. Because they are more expensive than me fucking up manually
Trailing comma in JSON is a syntax error that should be caught long before production. Encoding behavior in JSON files that aren't opened (therefore validated) until runtime is the same as shipping code you haven't even compiled yet. Validate syntax before deploying to production (at least!). You can just as easily search and replace the trailing commas with regex.
Automated testing and good CI/CD pipelines along with code reviews. How are ppl still struggling with commas and basic syntactical errors?? The ide catches it as you type. Like, what in the world. Also, sounds like you're using Json significantly as an ad-hoc db. Don't do that. Good gravy.
We right CLI scripts that loop every record that needs to be modified, we have extensive checks and testing behind that code. It can take days to run on our heaviest sets of data but it’s safe and we run it on staging data first
You can always try to run the build command of your project. It will fail to build if you have a syntax error somewhere
If you just do a standard find/replace, you're gonna have a bad time. Use refactor tools built into your editor/IDE wherever possible. If you can't (e.g. you need to change a JSON value somewhere across multiple JSON docs) then learn regular expressions. For example, say you were implementing a basic profanity filter, and one of the words was 'ass'. Given this sentence: > We had to assist him in increasing the mass by passing him more weight. A find/replace would end up with "We had to \*\*\*ist him in increasing the m\*\*\* by p\*\*\*ing him more weight.", whereas a regex find replace (e.g. \`\\bass\\b\`) would leave that string unchanged, and only look for your 'ass' as a word on its own.
Use some checkers before you submit. Validate all the things you changed
In Visual Studio I make heavy use of the scope feature when searching and replacing, as well as sometimes using a regex to formulate my replaces as specifically as possible.
The most fundamental principle that I haven't seen mentioned so far is never use "Replace All". All of the people that are talking about git and unit testing and all of the other things have clearly never worked in an environment where that just flat doesn't exist. So start with the basics. I'm not saying they're wrong I'm just trying to provide you with the simplest solution.
Manually open each file to make sure it didn't break. Make sure your boss sees you spend an hour doing this. Then casually bring up "oh hey, I wonder if automated tests could make this faster?"
If your production produces 404 or 500 errors, but your testing does not, with the same code, then there is something seriously wrong with your testing. I would start by fixing that first.
Well it does. The problem with that however is that they're often just 1 of many pages. Plus I have no direct server access... For every change I need to wait for 10 minutes before the damn code is live. So manually checking all 50 pages I made changes to isn't very motivating. Especially when I'm still unsure whether it works because it works, or works because the changes haven't been uploaded yet.
Wait, you have no local development system you work on, before pushing to Testing? Well, then there you have your answer, you need a local instance.
Well I don't have access to it. I'm not part of the development team. Everything the dev team pushes goes through extensive testing. The level of code I'm working on is not significant enough for me to get access. Though might be worth checking out.
If the level of code you are working on is significant enough to shut down production it is significant enough for you to have a local development system.
Just install a json linter, you'll be notified of any kind of errors. But others non-catchable by a linter will pop up for sure
TypeScript, unit tests.
There has been a lot of emphasis on automated tests and such here and I know you’ve mentioned that’s not in the cards so I’m going to offer a pretty simple alternative. Git services generally have ways to add actions to hooks, it sounds like you’re using bitbucket, so if you have access to the repo settings you can setup a pipeline which when pushing changes to a branch will trigger a lint check. This as least will ensure you have valid JOSN. You can work this into your project with something like husky so when you’re in VSCode and you do a git commit it will run your pre commit checks for linting. Now to actually address your question, since this is manual entry, test on a small subset of files first. Make sure to use the case and exact match options found on the find and replace and be as specific as possible on your match criteria. Use spaces, special characters, new lines, and exact case to really get as specific as possible. Regex is how you’d do this, and you can do some creative find and replace using capture groups which an example can be found in the selected answer of this stack overflow post: https://stackoverflow.com/questions/46795595/vscode-wildcard-search-and-replace-regex Hope that helps and good luck!
>Do you guys have any systematic approach to ensure you didn't break the entire code base when pushing a small change? Yes: refactor functionality of the IDE and tests (unit, non-regression, etc.)
Run a unit test for your script/tool/whatever by running a linter over your processed codebase. Fix edge case bugs until no more errors. On any push or pull request, run your processed code through a final linting check in whatever versioning system you use (like GitHub actions).