npm package: @k-int/bruno-shared-scripts
Description: This is a public NPM module dedicated to any shared behaviour required across varying collections in Bruno. For now it focuses mostly on connecting to a remote FOLIO instance and managing FOLIO headers, but there is nothing tying this module to only servi
Latest version: 2.0.6

# Bruno shared scripts

This is a public NPM module dedicated to any shared behaviour required across varying collections in Bruno. For now it
focuses mostly on connecting to a
remote FOLIO instance and managing FOLIO headers, but there is nothing tying this module to only serving those purposes.

## Motivation

Analogous to Postman's shared scripts cloud library, Bruno instead allows ANY NPM to be imported (In developer mode, via
`require`) and used within pre/post
request scripts. This is significantly more powerful and open, and allows us to publish the module onto the public NPM
with strict versioning and be more in
control.

## Setup

To use the shared scripts within a collection, simply import and initialise them.

```javascript
const {
  init,
} = require('@k-int/bruno-shared-scripts');

init({
  bruInstance: bru,
  logger: console,
  requestInstance: req
})
```

This init is a new requirement for Bruno V3, as the virtual environment the scripts are running in have now been
configured in such a way that third party modules do not get access to the globals previously available (bru, req), 
and access to the console in Bruno's developer tools is ALSO siloed.

To combat this, `init` at the collection level in the pre-request script will ensure that the module is able to 
access the functionality.

## How it works
The module is developed as an ES module, but needs to be built for publishing. This happens via the `npm run build`. 
This will overwrite the `es` directory, creating a single `index.js` file that can then be required by Bruno scripts.

## Development

Since this is an NPM, and Bruno collections can be built with NPM using a package.json, this _can_ be run in a 
workspace for "easy" development. However developing this module is not completely straightforward, and can take a while

### Working in a workspace
If working in an NPM workspace, as per [bienenvolk-bruno-workspace](https://gitlab.com/knowledge-integration/bruno/bienenvolk-bruno-workspace),
then the development process is:
- Make changes to shared scripts
- Run `build`
- Restart Bruno GUI 
  - IMPORTANT, Bruno caches the NPMs it's using per session, so any changes will NOT be visible until a restart
- Run request
- Go back to step 1

### Working without a workspace
The development process is largely the same as working in a workspace, with the only difference being that the 
version will need to point at the newest version

- Edit Bruno collection package.json to point the bruno-shared-scripts at `file:path/to/file`
- Run `build` for shared scripts
- clean `npm install` in the collection (Delete package lock and node_modules to be sure)
- Restart Bruno GUI
  - IMPORTANT, Bruno caches the NPMs it's using per session, so any changes will NOT be visible until a restart
- Run request
- Go back to step 2

And finally remembering to revert the version pointer at the end when the fixed shared-scripts have been published.

### Bruno globals
As of Bruno V3, access to `bru`, `req` and `console` will no longer behave as expected within a shared NPM. The 
solution to this is (for now) a file called `bruno-globals-provider`. This sets up a `setGlobals` method which in 
turn is used by init (I wanted to keep the globals setter separate from the init in case we have side effects down 
the road).

Then in each helper method, the requisite getter(s) can be used:

```javascript
import { getBru, getConsole, getReq } from '../bruno-globals-provider.js';

const helloWorld = () => {
  const bru = getBru();
  const logger = getConsole();
  const req = getReq();
  
  logger.log("Hello world");
  logger.log("Request: %o", req);
  
  logger.log("Access Bruno functionality: %o", bru.getEnv("FAKE_ENVIRONMENT_VARIABLE"));
}
```

Should post-request script helpers be needed, this will need to be extended to include `res` as well.