Port Heitor changes to previous versions

docs/sources/v0.47.x/using-k6/javascript-compatibility-mode.md

@@ -16,16 +16,16 @@ You can write k6 scripts in various ECMAScript versions:
 
 k6 supports both module types and most ES6+ features in all k6 execution modes: local, distributed, and cloud.
 
-Yet, to enable ES module support, k6 uses [Babel](https://babeljs.io/) internally to transform ESM to CommonJS. This process is as follows:
+To enable ES module support, k6 uses [Babel](https://babeljs.io/) internally to transform ESM to CommonJS. The process is as follows:
 
 ![Babel transformation in k6](/media/docs/k6-oss/diagram-grafana-k6-babel-pipeline.png)
 
-The k6 Babel transformation may slightly delay the startup for executing large scripts. Thus, some users prefer to bundle their test code outside k6. For this reason, k6 offers two JavaScript Compatibility modes:
+When executing large scripts, the k6 Babel transformation can slightly delay the startup time. Because of that, some users prefer to bundle their test code outside k6. For this reason, k6 offers two JavaScript compatibility modes:
 
-- [Extended mode](#extended-mode): The default, supporting ESM and most ES6+ features.
+- [Extended mode](#extended-mode): The default option, supporting ESM and most ES6+ features.
 - [Base mode](#base-mode): Limited to plain old JavaScript (ES5.1) and CommonJS, excluding the Babel step.
 
-When running tests, you can change the mode through the `--compatibility-mode` option:
+When running tests, you can change the mode by using the `--compatibility-mode` option:
 
 | Env                     | CLI                    | Code / Config file | Default      |
 | ----------------------- | ---------------------- | ------------------ | ------------ |
@@ -37,7 +37,7 @@ By default, k6 uses the `--compatibility-mode=extended` mode:
 
 {{< code >}}
 
-```default
+```bash
 $ k6 run script.js
 ```
 
@@ -61,9 +61,9 @@ $ K6_COMPATIBILITY_MODE=base k6 run script.js
 
 {{< /code >}}
 
-This mode omits the Babel transformation step, supporting only ES5.1+ code. You may want to enable this mode if your scripts are already written using only ES5.1 features, or were previously transformed by Babel.
+The base mode omits the Babel transformation step, supporting only ES5.1+ code. You may want to enable this mode if your scripts are already written using only ES5.1 features or were previously transformed by Babel.
 
-In general, this mode is not recommended as it offers minor benefits in reducing startup time.
+Generally, this mode is not recommended as it offers minor benefits in reducing startup time.
 
 ### CommonJS Example
 

docs/sources/v0.47.x/using-k6/modules.md

@@ -32,7 +32,7 @@ import http from 'k6/http';
 
 These modules are stored on the local filesystem, and accessed either through relative or absolute filesystem paths.
 
-k6 adopts a **brower-like module resolution** and does not support [Node.js module resolution](https://nodejs.org/api/modules.html#modules_all_together). File names for `imports` must be fully specified, such as `./helpers.js`.
+k6 adopts a **brower-like module resolution** and doesn't support [Node.js module resolution](https://nodejs.org/api/modules.html#modules_all_together). File names for `imports` must be fully specified, such as `./helpers.js`.
 
 ```javascript
 //my-test.js
@@ -102,15 +102,19 @@ export default function () {
 }
 ```
 
-How do k6 extensions (Go-to-JS modules) work? For enhanced performance, the k6 engine is written Go and embeds a JavaScript VM ([goja](https://github.com/dop251/goja)) to execute JavaScript test code. Thus, you can build your modules in Go code and import them as JavaScript as usual.
+How do k6 extensions (Go-to-JS modules) work? For enhanced performance, the k6 engine is written in Go and embeds a JavaScript VM ([goja](https://github.com/dop251/goja)) to execute JavaScript test code. That allows you to build your modules in Go code and import them as JavaScript as usual.
 
 To learn more about using or creating k6 extensions, refer to the [Extension documentation](https://grafana.com/docs/k6/<K6_VERSION>/extensions).
 
 ## Sharing JavaScript modules
 
-As mentioned previously, users can import custom Javascript libraries by loading either local or remote modules. Thus, we have two options to import JavaScript modules, along with various methods to distributed them.
+As mentioned previously, users can import custom JavaScript libraries by loading either local or remote modules. Because of that, we have two options to import JavaScript modules, along with various methods to distribute them.
 
-> The following options for distributing and sharing JavaScript libraries are available for both custom and other public libraries.
+{{< admonition type="note" >}}
+
+The following options for distributing and sharing JavaScript libraries are available for both custom and other public libraries.
+
+{{< /admonition >}}
 
 **As remote modules**
 
@@ -136,7 +140,7 @@ Be aware that k6 automatically executes remote modules, making it crucial to tru
 
 **As local modules**
 
-In this example, we've downloaded the previous remote modules in the `lib` folder of the testing project and imported them as follows:
+In this example, the previous remote modules have been downloaded to the `lib` folder of the testing project and imported as follows:
 
 ```javascript
 import { WorkloadConfig, sayHello } from './libs/test-commons.js';

docs/sources/v0.48.x/using-k6/javascript-compatibility-mode.md

@@ -16,16 +16,16 @@ You can write k6 scripts in various ECMAScript versions:
 
 k6 supports both module types and most ES6+ features in all k6 execution modes: local, distributed, and cloud.
 
-Yet, to enable ES module support, k6 uses [Babel](https://babeljs.io/) internally to transform ESM to CommonJS. This process is as follows:
+To enable ES module support, k6 uses [Babel](https://babeljs.io/) internally to transform ESM to CommonJS. The process is as follows:
 
 ![Babel transformation in k6](/media/docs/k6-oss/diagram-grafana-k6-babel-pipeline.png)
 
-The k6 Babel transformation may slightly delay the startup for executing large scripts. Thus, some users prefer to bundle their test code outside k6. For this reason, k6 offers two JavaScript Compatibility modes:
+When executing large scripts, the k6 Babel transformation can slightly delay the startup time. Because of that, some users prefer to bundle their test code outside k6. For this reason, k6 offers two JavaScript compatibility modes:
 
-- [Extended mode](#extended-mode): The default, supporting ESM and most ES6+ features.
+- [Extended mode](#extended-mode): The default option, supporting ESM and most ES6+ features.
 - [Base mode](#base-mode): Limited to plain old JavaScript (ES5.1) and CommonJS, excluding the Babel step.
 
-When running tests, you can change the mode through the `--compatibility-mode` option:
+When running tests, you can change the mode by using the `--compatibility-mode` option:
 
 | Env                     | CLI                    | Code / Config file | Default      |
 | ----------------------- | ---------------------- | ------------------ | ------------ |
@@ -37,7 +37,7 @@ By default, k6 uses the `--compatibility-mode=extended` mode:
 
 {{< code >}}
 
-```default
+```bash
 $ k6 run script.js
 ```
 
@@ -61,9 +61,9 @@ $ K6_COMPATIBILITY_MODE=base k6 run script.js
 
 {{< /code >}}
 
-This mode omits the Babel transformation step, supporting only ES5.1+ code. You may want to enable this mode if your scripts are already written using only ES5.1 features, or were previously transformed by Babel.
+The base mode omits the Babel transformation step, supporting only ES5.1+ code. You may want to enable this mode if your scripts are already written using only ES5.1 features or were previously transformed by Babel.
 
-In general, this mode is not recommended as it offers minor benefits in reducing startup time.
+Generally, this mode is not recommended as it offers minor benefits in reducing startup time.
 
 ### CommonJS Example
 

docs/sources/v0.48.x/using-k6/modules.md

@@ -32,7 +32,7 @@ import http from 'k6/http';
 
 These modules are stored on the local filesystem, and accessed either through relative or absolute filesystem paths.
 
-k6 adopts a **brower-like module resolution** and does not support [Node.js module resolution](https://nodejs.org/api/modules.html#modules_all_together). File names for `imports` must be fully specified, such as `./helpers.js`.
+k6 adopts a **brower-like module resolution** and doesn't support [Node.js module resolution](https://nodejs.org/api/modules.html#modules_all_together). File names for `imports` must be fully specified, such as `./helpers.js`.
 
 ```javascript
 //my-test.js
@@ -102,15 +102,19 @@ export default function () {
 }
 ```
 
-How do k6 extensions (Go-to-JS modules) work? For enhanced performance, the k6 engine is written Go and embeds a JavaScript VM ([goja](https://github.com/dop251/goja)) to execute JavaScript test code. Thus, you can build your modules in Go code and import them as JavaScript as usual.
+How do k6 extensions (Go-to-JS modules) work? For enhanced performance, the k6 engine is written in Go and embeds a JavaScript VM ([goja](https://github.com/dop251/goja)) to execute JavaScript test code. That allows you to build your modules in Go code and import them as JavaScript as usual.
 
 To learn more about using or creating k6 extensions, refer to the [Extension documentation](https://grafana.com/docs/k6/<K6_VERSION>/extensions).
 
 ## Sharing JavaScript modules
 
-As mentioned previously, users can import custom Javascript libraries by loading either local or remote modules. Thus, we have two options to import JavaScript modules, along with various methods to distributed them.
+As mentioned previously, users can import custom JavaScript libraries by loading either local or remote modules. Because of that, we have two options to import JavaScript modules, along with various methods to distribute them.
 
-> The following options for distributing and sharing JavaScript libraries are available for both custom and other public libraries.
+{{< admonition type="note" >}}
+
+The following options for distributing and sharing JavaScript libraries are available for both custom and other public libraries.
+
+{{< /admonition >}}
 
 **As remote modules**
 
@@ -136,7 +140,7 @@ Be aware that k6 automatically executes remote modules, making it crucial to tru
 
 **As local modules**
 
-In this example, we've downloaded the previous remote modules in the `lib` folder of the testing project and imported them as follows:
+In this example, the previous remote modules have been downloaded to the `lib` folder of the testing project and imported as follows:
 
 ```javascript
 import { WorkloadConfig, sayHello } from './libs/test-commons.js';

docs/sources/v0.49.x/using-k6/javascript-compatibility-mode.md

@@ -16,16 +16,16 @@ You can write k6 scripts in various ECMAScript versions:
 
 k6 supports both module types and most ES6+ features in all k6 execution modes: local, distributed, and cloud.
 
-Yet, to enable ES module support, k6 uses [Babel](https://babeljs.io/) internally to transform ESM to CommonJS. This process is as follows:
+To enable ES module support, k6 uses [Babel](https://babeljs.io/) internally to transform ESM to CommonJS. The process is as follows:
 
 ![Babel transformation in k6](/media/docs/k6-oss/diagram-grafana-k6-babel-pipeline.png)
 
-The k6 Babel transformation may slightly delay the startup for executing large scripts. Thus, some users prefer to bundle their test code outside k6. For this reason, k6 offers two JavaScript Compatibility modes:
+When executing large scripts, the k6 Babel transformation can slightly delay the startup time. Because of that, some users prefer to bundle their test code outside k6. For this reason, k6 offers two JavaScript compatibility modes:
 
-- [Extended mode](#extended-mode): The default, supporting ESM and most ES6+ features.
+- [Extended mode](#extended-mode): The default option, supporting ESM and most ES6+ features.
 - [Base mode](#base-mode): Limited to plain old JavaScript (ES5.1) and CommonJS, excluding the Babel step.
 
-When running tests, you can change the mode through the `--compatibility-mode` option:
+When running tests, you can change the mode by using the `--compatibility-mode` option:
 
 | Env                     | CLI                    | Code / Config file | Default      |
 | ----------------------- | ---------------------- | ------------------ | ------------ |
@@ -37,7 +37,7 @@ By default, k6 uses the `--compatibility-mode=extended` mode:
 
 {{< code >}}
 
-```default
+```bash
 $ k6 run script.js
 ```
 
@@ -61,9 +61,9 @@ $ K6_COMPATIBILITY_MODE=base k6 run script.js
 
 {{< /code >}}
 
-This mode omits the Babel transformation step, supporting only ES5.1+ code. You may want to enable this mode if your scripts are already written using only ES5.1 features, or were previously transformed by Babel.
+The base mode omits the Babel transformation step, supporting only ES5.1+ code. You may want to enable this mode if your scripts are already written using only ES5.1 features or were previously transformed by Babel.
 
-In general, this mode is not recommended as it offers minor benefits in reducing startup time.
+Generally, this mode is not recommended as it offers minor benefits in reducing startup time.
 
 ### CommonJS Example
 

docs/sources/v0.49.x/using-k6/modules.md

@@ -32,7 +32,7 @@ import http from 'k6/http';
 
 These modules are stored on the local filesystem, and accessed either through relative or absolute filesystem paths.
 
-k6 adopts a **brower-like module resolution** and does not support [Node.js module resolution](https://nodejs.org/api/modules.html#modules_all_together). File names for `imports` must be fully specified, such as `./helpers.js`.
+k6 adopts a **brower-like module resolution** and doesn't support [Node.js module resolution](https://nodejs.org/api/modules.html#modules_all_together). File names for `imports` must be fully specified, such as `./helpers.js`.
 
 ```javascript
 //my-test.js
@@ -102,15 +102,19 @@ export default function () {
 }
 ```
 
-How do k6 extensions (Go-to-JS modules) work? For enhanced performance, the k6 engine is written Go and embeds a JavaScript VM ([goja](https://github.com/dop251/goja)) to execute JavaScript test code. Thus, you can build your modules in Go code and import them as JavaScript as usual.
+How do k6 extensions (Go-to-JS modules) work? For enhanced performance, the k6 engine is written in Go and embeds a JavaScript VM ([goja](https://github.com/dop251/goja)) to execute JavaScript test code. That allows you to build your modules in Go code and import them as JavaScript as usual.
 
 To learn more about using or creating k6 extensions, refer to the [Extension documentation](https://grafana.com/docs/k6/<K6_VERSION>/extensions).
 
 ## Sharing JavaScript modules
 
-As mentioned previously, users can import custom Javascript libraries by loading either local or remote modules. Thus, we have two options to import JavaScript modules, along with various methods to distributed them.
+As mentioned previously, users can import custom JavaScript libraries by loading either local or remote modules. Because of that, we have two options to import JavaScript modules, along with various methods to distribute them.
 
-> The following options for distributing and sharing JavaScript libraries are available for both custom and other public libraries.
+{{< admonition type="note" >}}
+
+The following options for distributing and sharing JavaScript libraries are available for both custom and other public libraries.
+
+{{< /admonition >}}
 
 **As remote modules**
 
@@ -136,7 +140,7 @@ Be aware that k6 automatically executes remote modules, making it crucial to tru
 
 **As local modules**
 
-In this example, we've downloaded the previous remote modules in the `lib` folder of the testing project and imported them as follows:
+In this example, the previous remote modules have been downloaded to the `lib` folder of the testing project and imported as follows:
 
 ```javascript
 import { WorkloadConfig, sayHello } from './libs/test-commons.js';