Just like lodash, exports from aws-sdk must not be imported from its root, but from a specific path, such as aws-sdk/clients/.....

This is because aws-sdk is included as cjs in the lambda runtime but cannot be tree-shaked. This is a big performance issue.

I have generated a plop library and launched yarn test at the root of my project.

Test unit tests fail with error message

packages/plop/jest.config.ts' is not under 'rootDir' 'packages/plop/src'. 'rootDir' is expected to contain all source files.
         The file is in the program because:
           Matched by include pattern './**/*.ts' in 'packages/plop/tsconfig.json'

It seems that moving to yarn@3 has broken this feature

Currenly the test is not easily understandable and will not catch a function name with exactly 64 characters

We are currently stuck with the yarn v1, which is no longer under active development.

I think we need to investigate yarn v2 and check whether some quick wins could enable us to keep our key features with this new version.

In a service declaring no function, testFunctionName would fail.
We could add that case to the test

eslint is not run in the generators workspace in VS Code.

In order to setup a coherent release flow between our template and the swarmion tools, we need to move the template to https://github.com/swarmion/swarmion, in the examples folder.

This will also enable us to have multiple available starter, all in the same place.

The migration is in progress.

It would be great to set:

 "nx": {
    "targets": {
      "package": {
        "outputs": [
          "contracts/core-contracts/dist"
        ]
      }
    }
  }

during library generation !

See #79

Force imports to be done at the highest level
🚫 import myFunction from '@sls-monorepo/blob/lib/myFile.ts
✔️ import { myFunction } from '@sls-monorepo/blob

Why: this undermines the whole segregation process in the monorepo, since the imported file would be built by the caller and not the callee