Add repl

node.js/cds-compile.md

@@ -179,7 +179,8 @@ console.log (edm)
 ```js
 // for all services
 let all = cds.compile.to.edm (csn, {service:'all'})
-for (let [edm,{file,suffix}] of all)  console.log (file,suffix,edm)
+for (let [edm,{file,suffix}] of all)  
+console.log (file,suffix,edm)
 ```
 
 
@@ -197,7 +198,7 @@ For example, use it as follows:
 ```js
 let all = cds.compile.to.hdbtable (csn)
 for (let [src,{file}] of all)
-  console.log (file,src)
+console.log (file,src)
 ```
 
 
@@ -402,12 +403,13 @@ If no files are found, `undefined` is returned.
 Examples:
 
 ```js
-cds.env.folders           // = folders db, srv, app by default
-cds.env.roots             // + schema and services in cwd
-cds.resolve('*',false)    // + models in cds.env.requires
-cds.resolve('*')          // > the resolved existing files
-cds.resolve(['db'])       // > the resolved existing files
-cds.resolve(['db','srv']) // > the resolved existing files
-cds.resolve('none')       // > undefined
+[dev] cds repl
+> cds.env.folders           // = folders db, srv, app by default
+> cds.env.roots             // + schema and services in cwd
+> cds.resolve('*',false)    // + models in cds.env.requires
+> cds.resolve('*')          // > the resolved existing files
+> cds.resolve(['db'])       // > the resolved existing files
+> cds.resolve(['db','srv']) // > the resolved existing files
+> cds.resolve('none')       // > undefined
 ```
-> Try this in cds repl launched from your project root to see that in action.
+> Try this in cds repl launched from your project root to see that in action.

node.js/cds-facade.md

@@ -138,7 +138,7 @@ if (major < 6) // code for pre cds6 usage
 
 Returns the pathname of the `@sap/cds` installation folder from which the current instance of the `cds` facade module was loaded.
 
-```log
+```js
 [dev] cds repl
 > cds.home // [!code focus]
 ~/.npm/lib/node_modules/@sap/cds
@@ -176,7 +176,7 @@ Trace : {
 }
 ```
 
-For example, [`cds-plugins`](cds-serve) can use that to plugin to different parts of the framework for different commands being executed.
+For example, [`cds-plugins`](cds-serve) can use that to plug into different parts of the framework for different commands being executed.
 
 
 
@@ -185,7 +185,7 @@ For example, [`cds-plugins`](cds-serve) can use that to plugin to different part
 
 Provides access to the effective configuration of the current process, transparently from various sources, including the local _package.json_ or _.cdsrc.json_, service bindings and process environments.
 
-```console
+```js
 [dev] cds repl
 > cds.env.requires.auth // [!code focus]
 {
@@ -232,24 +232,27 @@ service ReviewsService {}
 You can access the entries as follows:
 
 ```js
-cds.env.requires.db              //> the effective config for db
-cds.env.requires.reviews         //> the effective config for reviews
-cds.env.requires.ReviewsService  //> undefined
+[dev] cds repl
+> cds.env.requires.db              //> the effective config for db
+> cds.env.requires.reviews         //> the effective config for reviews
+> cds.env.requires.ReviewsService  //> undefined
 ```
 
 ```js
-cds.requires.db                  //> the effective config for db
-cds.requires.reviews             //> the effective config for reviews
-cds.requires.ReviewsService      //> same as cds.requires.reviews
+[dev] cds repl
+> cds.requires.db                  //> the effective config for db
+> cds.requires.reviews             //> the effective config for reviews
+> cds.requires.ReviewsService      //> same as cds.requires.reviews
 ```
 
 The additional entries are useful for code that needs to securely access the service by cds definition name.
 
 Note: as `cds.requires` is an overlay to `cds.env.requires`, it inherits all properties from there via prototype chain. In effect using operations which only look at *own* properties, like `Object.keys()` behave different than for `cds.env.requires`:
 
 ```js
-Object.keys(cds.env.requires) //> [ 'db', 'reviews' ]
-Object.keys(cds.requires)     //> [ 'ReviewsService' ]
+[dev] cds repl
+> Object.keys(cds.env.requires) //> [ 'db', 'reviews' ]
+> Object.keys(cds.requires)     //> [ 'ReviewsService' ]
 ```
 
 

node.js/cds-server.md

@@ -10,7 +10,7 @@ status: released
 
 
 
-CAP Node.js servers a bootstrapped through a [built-in `server.js` module](#built-in-server-js), which can be accessed through [`cds.server`](#cds-server). You can plug-in custom logic to the default bootstrapping choreography using a [custom `server.js`](#custom-server-js) in your project.
+CAP Node.js servers are bootstrapped through a [built-in `server.js` module](#built-in-server-js), which can be accessed through [`cds.server`](#cds-server). You can plug-in custom logic to the default bootstrapping choreography using a [custom `server.js`](#custom-server-js) in your project.
 
 
 
@@ -121,7 +121,7 @@ module.exports = (o)=>{
 }
 ```
 
-::: tip
+::: tip `req` != `req`
 The `req` object in your express middleware is not the same as `req` in your CDS event handlers.
 :::
 

node.js/events.md

@@ -24,12 +24,13 @@ Usually that context is set by inbound middleware.
 The property is realized as a so-called continuation-local variable, implemented using [Node.js' async local storage](https://nodejs.org/api/async_context.html) technique, and a getter/setter pair: The getter is a shortcut for[`getStore()`](https://nodejs.org/api/async_context.html#asynclocalstoragegetstore). The setter coerces values into valid instances of [`cds.EventContext`]. For example:
 
 ```js
-cds.context = { tenant:'t1', user:'u2' }
-let ctx = cds.context
-ctx instanceof cds.EventContext  //> true
-ctx.user instanceof cds.User     //> true
-ctx.tenant === 't1'              //> true
-ctx.user.id === 'u2'             //> true
+[dev] cds repl
+> cds.context = { tenant:'t1', user:'u2' }
+> let ctx = cds.context
+> ctx instanceof cds.EventContext  //> true
+> ctx.user instanceof cds.User     //> true
+> ctx.tenant === 't1'              //> true
+> ctx.user.id === 'u2'             //> true
 ```
 
 If a transaction object is assigned, its `tx.context` is used, hence `cds.context = tx` acts as a convenience shortcut for `cds.context = tx.context`:

node.js/messaging.md

@@ -361,9 +361,8 @@ Example:
 <!-- ``` -->
 If your server is authenticated using [XSUAA](authentication#jwt), you need to grant the scope `$XSAPPNAME.emcallback` to SAP Event Mesh for it to be able to trigger the handshake and send messages.
 
-In _xs-security.json_:
-
-```js
+::: code-group
+```js [xs-security.json]
 {
   ...,
   "scopes": [
@@ -378,6 +377,7 @@ In _xs-security.json_:
   ]
 }
 ```
+:::
 
 Make sure to add this to the service descriptor of your SAP Event Mesh instance: