Use 2022 throughout

Done

Can this go up on line 22?

Done

I think slightly easier to read as async function callImportUserEvents() {

The arrow function is a popular features of ES6, it has become a standard as it is more compact and actually convenient to read. If you have any doubts, please create an Issue and we will update the whole code we have submitted with such code style. will it work for you?

I'd rather not rely on env variables if possible, especially for running tests locally. If your tutorial relies on it, it's fine but I'd rather users have to specifically change these variables.

this tests should not be run locally. for the kokoro test run we have the long-living resources created. And the code samples itself will run in the CloudShell environment, we provide user with the guide how to create the required resources: service account, buckets, big query tables, and set their names as env variables

On the top of these variables, can we add something like TODO(developer): uncomment these variables and fill appropriately so that people know to change them? We should also bring up line 30 under line 24 so users know to change that variable.

same comment, would rather this not be an env variable.

We received a task to change the approach of reading the ProjectId value fron the env variable, but to read it from gcloud config or from google.auth instead. We are working on this task Now and the new Pull request will be introduced shortly

Is this a sample? We don't have region tags, or a lot of the normal strucutre.

it is not a sample, this is the supporting code for the uploading the catalog data

missing region tags

this is not the Retail code sample it is the supporting code for the uploading the catalog data
won't fix

In order to avoid using env variables, especially for running tests locally, we can require a projectId variable, and in the test, instantiate it like so:

const client = new UserEventServiceClient();
describe('test', () => {
  let projectId;

  before(async () => {
    projectId = await client.getProjectId();
  });

this is not a regular code samples, this is the code for interactive tutorials, the concept is a bit different. The tests here are developed only to make sure the tutorials are not broken, ti is not the desired flow if user will run the tests locally

there was a task we've got recently, the project Id should be read from the google auth or from the gcloud config, so we are working on this task and the PR will be created shortly

I'm probably just out of context here, so take this comment with a grain of salt, but I generally don't feel like the use of utils is beneficial in samples. If someone is really trying to follow this sample, it's harder to read when the code is splintered like this. Of course there are good reasons for using utils, but just my thoughts from the perspective of someone trying to use this sample (i.e., they can't just "copy and paste")

Hi @sofisl, let me describe a bit the purpose of these code. It is Not the regular code samples which are in this repository.
The task is to design the interactive tutorials which user will be able to run in CloudShell.
In the tutorials we ask user to set a GC project, and create a user account, and then user should open and run in the CloudShell the code samples. The tutorials are really granular, if it is about product updating we want show user only code related to using this method, and to avoid to overload user with extra code. so for theis particular example, we want to hide the methods for product creation and deletion in utils and present only the the update product method.

About using the env variables. We must use them for the bucket names (we use GCS buckets as an importing source) but we will make the Project_ID to be read from the gcloud config.