Typerepo

The new way to dev

README

Get path

get-path (

OperationClassification

OperationClassification tells you to what kind of environment the operation can be exposed to. It tells you things about how it will be built. There are three categories: Full stack, frontend only, and backend only. The aim is to do as much as possible in the full stack realm so it can be reused anywhere. If that is not possible, ui-esm is preferred for the frontend, or node-esm for things that require backend.

TODO: It would be great to learn more about this topic and see if I can make more cross-environment packages. A great use case would be to create a wrapper around the current fs-orm to enable using it at the frontend too.

Possible values

FULL STACK

cjs: only js (no node) (well, ts of course, but it gets built into common js)
ts: non-built typescript code (needs to be transpiled, not recommended)

TODO: esm: builds to ESM module resolved Javascript

FRONTEND ONLY (cannot be used within backend-only operations)

ui-web: has next.config.js and thus exposes something on some port when it is ran. next.js + react-based...
ui-app: uses react-native and exposes something on some port when it is ran
ui-ts: uses react (with (native)), which main entry points to typescript es6 files (this ui package cannot be built, should be transpiled. Primarily used for big ui libraries tied to a ui-web and ui-app for convenience. For other things, it is highly discouraged, please use ui-cjs or ui-esm)
ui-cjs: ui which main entry points to javascript es5 files (this ui package can be built). don't import ESM packages in here, this may give problems.
ui-esm: ui which builds to ESM module resolved Javascript. All packages that use ui-esm packages, need to be ui-esm, ui-es6, ui-web, or ui-app in order to work properly. It seems to have difficulties using this in ui-cjs

BACKEND ONLY (cannot be used within frontend-only operations)

node-cjs: includes other node packages, operations, core-imports, and globals.

TODO: node-esm: Typescript package that is built to ESM Javascript which also includes all node packages, operations, core-imports and globals.

TODO: node-ts: transpilable node package

server-cjs: exposes something on some port when it is ran and uses node code

Indexation

Operations will be classified automatically. It is good to remember that:

It will be classified as UI if isUiOperation resolves to true
It will be classified as Node if Operation has a (dev)dependency on @types/node.
Otherwise, it will be classified as base typescript (full stack)
It will be classified to an ESM operation if tsconfigCompilesEsm resolves to true.
It will be classified to a TS operation if packageCompilesTs resolves to true
In order for it to be classified as a server, you must set isNodeServer to true in the operation config object of Operation

OperationClassification cjs)

Useful functions to get paths within King OS.

Depends on

sdk-operations

Generated operation that exports an object that contains all names of all operations as keys, and all project relative paths to those operations as values.

Needed to find files more quickly in a more performant way.

When moving operations around, ensure to regenerate this to avoid conflicts.

sdk-operations, which makes it only work inside of a typerepo.

Api reference

getProjectRoot()

returns project root folder path

recursive. goes up until it finds a folder that's the project root

if no source path is given, uses the directory name where the function is executed from as a starting point

Input
fullSourcePath (optional)	string
Output	string

📄 getProjectRoot (exported const)

returns project root folder path

recursive. goes up until it finds a folder that's the project root

if no source path is given, uses the directory name where the function is executed from as a starting point

getOperationPath()

Gets a path of any operation in the project

NB: relies on

sdk-operations

Generated operation that exports an object that contains all names of all operations as keys, and all project relative paths to those operations as values.

Needed to find files more quickly in a more performant way.

When moving operations around, ensure to regenerate this to avoid conflicts.

sdk-operations 100%

Input
operationName	string	specify the operation folder name
Output

📄 getOperationPath (exported const)

getRootPath()

Gets project path, or a folder in the root that is convention

Input
-
Output	string

📄 getRootPath (exported const)

findOperationBasePath()

Input
startPath	string
Output	string

📄 findOperationBasePath (exported const)

getPathsWithOperations()

returns an array of all (absolute) paths containing operations

for a bundled project, that means /apps, /packages, /modules

for the OS project, that means /operations/tools and /operations/niches

Input
config (optional)	{ manualProjectRoot?: string, }
Output	string[]

📄 getPathsWithOperations (exported const)

returns an array of all (absolute) paths containing operations

for a bundled project, that means /apps, /packages, /modules

for the OS project, that means /operations/tools and /operations/niches

getSrcRelativeFileId()

returns a file id (path without extension) relative to the src folder of an operation

e.g. "general" for src/general.ts

NB: assumes all src is in the src folder

NB: removes "/" in the beginning, if found

Input
operationRelativePath	string
Output

📄 getSrcRelativeFileId (exported const)

returns a file id (path without extension) relative to the src folder of an operation

e.g. "general" for src/general.ts

NB: assumes all src is in the src folder

NB: removes "/" in the beginning, if found

getOperationClassification()

Returns

OperationClassification

Possible values

FULL STACK

cjs: only js (no node) (well, ts of course, but it gets built into common js)
ts: non-built typescript code (needs to be transpiled, not recommended)

TODO: esm: builds to ESM module resolved Javascript

FRONTEND ONLY (cannot be used within backend-only operations)

ui-web: has next.config.js and thus exposes something on some port when it is ran. next.js + react-based...
ui-app: uses react-native and exposes something on some port when it is ran
ui-ts: uses react (with (native)), which main entry points to typescript es6 files (this ui package cannot be built, should be transpiled. Primarily used for big ui libraries tied to a ui-web and ui-app for convenience. For other things, it is highly discouraged, please use ui-cjs or ui-esm)
ui-cjs: ui which main entry points to javascript es5 files (this ui package can be built). don't import ESM packages in here, this may give problems.
ui-esm: ui which builds to ESM module resolved Javascript. All packages that use ui-esm packages, need to be ui-esm, ui-es6, ui-web, or ui-app in order to work properly. It seems to have difficulties using this in ui-cjs

BACKEND ONLY (cannot be used within frontend-only operations)

node-cjs: includes other node packages, operations, core-imports, and globals.

TODO: node-esm: Typescript package that is built to ESM Javascript which also includes all node packages, operations, core-imports and globals.

TODO: node-ts: transpilable node package

server-cjs: exposes something on some port when it is ran and uses node code

Indexation

Operations will be classified automatically. It is good to remember that:

It will be classified as UI if isUiOperation resolves to true
It will be classified as Node if Operation has a (dev)dependency on @types/node.
Otherwise, it will be classified as base typescript (full stack)
It will be classified to an ESM operation if tsconfigCompilesEsm resolves to true.
It will be classified to a TS operation if packageCompilesTs resolves to true
In order for it to be classified as a server, you must set isNodeServer to true in the operation config object of Operation

OperationClassification if it's an operation, or undefined if it's not

NB: don't confuse this with

ImportClassification

node: node core packages like fs and path

react: react standard packages like react, react-native, expo, react-dom, etc.

package: packages from npm that are not classified as operations

operation: operations from our monorepo

internal: imports from other places in the same operation

NB: don't confuse this with OperationClassification

ImportClassification

Input
folderPath	string
Output

isBundle()

Input
folderPath (optional)	string
Output	{ }

📄 getOperationClassification (exported const)

Returns

OperationClassification

Possible values

FULL STACK

cjs: only js (no node) (well, ts of course, but it gets built into common js)
ts: non-built typescript code (needs to be transpiled, not recommended)

TODO: esm: builds to ESM module resolved Javascript

FRONTEND ONLY (cannot be used within backend-only operations)

ui-web: has next.config.js and thus exposes something on some port when it is ran. next.js + react-based...
ui-app: uses react-native and exposes something on some port when it is ran
ui-ts: uses react (with (native)), which main entry points to typescript es6 files (this ui package cannot be built, should be transpiled. Primarily used for big ui libraries tied to a ui-web and ui-app for convenience. For other things, it is highly discouraged, please use ui-cjs or ui-esm)
ui-cjs: ui which main entry points to javascript es5 files (this ui package can be built). don't import ESM packages in here, this may give problems.
ui-esm: ui which builds to ESM module resolved Javascript. All packages that use ui-esm packages, need to be ui-esm, ui-es6, ui-web, or ui-app in order to work properly. It seems to have difficulties using this in ui-cjs

BACKEND ONLY (cannot be used within frontend-only operations)

node-cjs: includes other node packages, operations, core-imports, and globals.

TODO: node-esm: Typescript package that is built to ESM Javascript which also includes all node packages, operations, core-imports and globals.

TODO: node-ts: transpilable node package

server-cjs: exposes something on some port when it is ran and uses node code

Indexation

Operations will be classified automatically. It is good to remember that:

It will be classified as UI if isUiOperation resolves to true
It will be classified as Node if Operation has a (dev)dependency on @types/node.
Otherwise, it will be classified as base typescript (full stack)
It will be classified to an ESM operation if tsconfigCompilesEsm resolves to true.
It will be classified to a TS operation if packageCompilesTs resolves to true
In order for it to be classified as a server, you must set isNodeServer to true in the operation config object of Operation

OperationClassification if it's an operation, or undefined if it's not

NB: don't confuse this with

ImportClassification

node: node core packages like fs and path

react: react standard packages like react, react-native, expo, react-dom, etc.

package: packages from npm that are not classified as operations

operation: operations from our monorepo

internal: imports from other places in the same operation

NB: don't confuse this with OperationClassification

ImportClassification

📄 isBundle (exported const)

getOperationRelativePath()

something like src/xxx/xxx/x.ts (no slash at start)

Input
absolutePath	string
Output

📄 getOperationRelativePath (exported const)

something like src/xxx/xxx/x.ts (no slash at start)

getOperationClassificationObject()

Input
-
Output

getOperationPathParse()

get all operation-related path information that can be inferred from the path

NB: currently it also looks up the operation name from its packagejson

Input
absolutePath	string
Output

getPathParse()

gets all kinds of information that can be inferred from any path (file or folder).

Input
absolutePath	string
Output	{ relativePathFromProjectRoot: string, }

📄 getOperationClassificationObject (exported const)

📄 getOperationPathParse (exported const)

get all operation-related path information that can be inferred from the path

NB: currently it also looks up the operation name from its packagejson

📄 getPathParse (exported const)

gets all kinds of information that can be inferred from any path (file or folder).

getRelativeLinkPath()

returns a relative link between two files

Input
absoluteFromFilePath	string
Output	`String`

getSubExtensions()

Input
absolutePath	string
Output	string[]

isOperation()

Checks whether or not an absolute path contains an operation. The only check it's doing is that the folder must contain both a package.json as well as a tsconfig.json

Input
absoluteFolderPath	string
Output	{ }

🔹 OperationClassificationObject

📄 getRelativeLinkPath (exported const)

returns a relative link between two files

📄 getSubExtensions (exported const)

📄 isOperation (exported const)

Checks whether or not an absolute path contains an operation. The only check it's doing is that the folder must contain both a package.json as well as a tsconfig.json

Tests

Show test information(2)

test()

Input
-
Output

📄 test (unexported const)

Internal

Show internal (24)

findFolderWhereMatch()

recursive. goes up a folder until it finds a package.json

Input
-
Output	{ folderPath: string, matchResult: { }, }

findOperationBasePathWithClassification()

recursive. goes up until it finds a folder that's an operation

because it had to read the package.json anyway, it's returning the operation classification as well

Input
startPath	string
Output	{ folderPath: string, classification: { }, }

getAllPackageJsonDependencies()

Input
operation	Operation Model for `typerepo` operations. Stored in `package.json` in every package (compatible with regular npm package.json data structure). An `Operation` is a NPM Package that applies the `typerepo` convention. TODO: add a validation to package.json files for the whole project, to ensure i can apply `fs-orm` convention Operation
Output	string[]

getCommonAncestor()

Finds the common ancestor for two absolute pahts

Input
path1	string
Output	`String`

getRelativePath()

gets the relative path from a specified root

will start with "/"

Input
absolutePath	string
Output

hasDependency()

Input
operation	Operation Model for `typerepo` operations. Stored in `package.json` in every package (compatible with regular npm package.json data structure). An `Operation` is a NPM Package that applies the `typerepo` convention. TODO: add a validation to package.json files for the whole project, to ensure i can apply `fs-orm` convention Operation
Output

isUiOperation()

Input
tsconfig	{ }
Output

isWorkspaceRoot()

simple sync function to check if a folder is the root of a workspace (not operation but a workspace)

Input
folderPath	string
Output	{ isBundle: boolean, isWorkspaceRoot: boolean, }

packageCompilesTs()

Input
packageJson	{ }
Output

tsconfigCompilesEsm()

Input
tsconfig	TsConfig would be nice if we have a type interface for this, just like package.json for now just type the stuff we need TsConfig
Output	{ }

📄 findFolderWhereMatch (exported const)

recursive. goes up a folder until it finds a package.json

📄 findOperationBasePathWithClassification (exported const)

recursive. goes up until it finds a folder that's an operation

because it had to read the package.json anyway, it's returning the operation classification as well

📄 getAllPackageJsonDependencies (exported const)

📄 getCommonAncestor (exported const)

Finds the common ancestor for two absolute pahts

📄 getRelativePath (exported const)

gets the relative path from a specified root

will start with "/"

📄 hasDependency (exported const)

📄 isUiOperation (exported const)

📄 isWorkspaceRoot (exported const)

simple sync function to check if a folder is the root of a workspace (not operation but a workspace)

📄 osRootFoldersConst (exported const)

can only be accessed in the OS

📄 osRootFolders (exported const)

📄 packageCompilesTs (exported const)

📄 projectRootFoldersConst (exported const)

can be accessed in projects as well as in the OS

📄 projectRootFolders (exported const)

📄 tsconfigCompilesEsm (exported const)

get-package-source-paths

⬅

get-ts-config

➡

🏰

Typerepo

The new way to dev

GitHub

README

Get path

get-path (

OperationClassification

Possible values

FULL STACK

cjs: only js (no node) (well, ts of course, but it gets built into common js)
ts: non-built typescript code (needs to be transpiled, not recommended)

TODO: esm: builds to ESM module resolved Javascript

FRONTEND ONLY (cannot be used within backend-only operations)

ui-web: has next.config.js and thus exposes something on some port when it is ran. next.js + react-based...
ui-app: uses react-native and exposes something on some port when it is ran
ui-ts: uses react (with (native)), which main entry points to typescript es6 files (this ui package cannot be built, should be transpiled. Primarily used for big ui libraries tied to a ui-web and ui-app for convenience. For other things, it is highly discouraged, please use ui-cjs or ui-esm)
ui-cjs: ui which main entry points to javascript es5 files (this ui package can be built). don't import ESM packages in here, this may give problems.
ui-esm: ui which builds to ESM module resolved Javascript. All packages that use ui-esm packages, need to be ui-esm, ui-es6, ui-web, or ui-app in order to work properly. It seems to have difficulties using this in ui-cjs

BACKEND ONLY (cannot be used within frontend-only operations)

node-cjs: includes other node packages, operations, core-imports, and globals.

TODO: node-esm: Typescript package that is built to ESM Javascript which also includes all node packages, operations, core-imports and globals.

TODO: node-ts: transpilable node package

server-cjs: exposes something on some port when it is ran and uses node code

Indexation

Operations will be classified automatically. It is good to remember that:

It will be classified as UI if isUiOperation resolves to true
It will be classified as Node if Operation has a (dev)dependency on @types/node.
Otherwise, it will be classified as base typescript (full stack)
It will be classified to an ESM operation if tsconfigCompilesEsm resolves to true.
It will be classified to a TS operation if packageCompilesTs resolves to true
In order for it to be classified as a server, you must set isNodeServer to true in the operation config object of Operation

OperationClassification cjs)

Useful functions to get paths within King OS.

Depends on

sdk-operations

Generated operation that exports an object that contains all names of all operations as keys, and all project relative paths to those operations as values.

Needed to find files more quickly in a more performant way.

When moving operations around, ensure to regenerate this to avoid conflicts.

sdk-operations, which makes it only work inside of a typerepo.

Api reference

getProjectRoot()

returns project root folder path

recursive. goes up until it finds a folder that's the project root

if no source path is given, uses the directory name where the function is executed from as a starting point

Input
fullSourcePath (optional)	string
Output	string

📄 getProjectRoot (exported const)

returns project root folder path

recursive. goes up until it finds a folder that's the project root

if no source path is given, uses the directory name where the function is executed from as a starting point

getOperationPath()

Gets a path of any operation in the project

NB: relies on

sdk-operations

Generated operation that exports an object that contains all names of all operations as keys, and all project relative paths to those operations as values.

Needed to find files more quickly in a more performant way.

When moving operations around, ensure to regenerate this to avoid conflicts.

sdk-operations 100%

Input
operationName	string	specify the operation folder name
Output

📄 getOperationPath (exported const)

getRootPath()

Gets project path, or a folder in the root that is convention

Input
-
Output	string

📄 getRootPath (exported const)

findOperationBasePath()

Input
startPath	string
Output	string

📄 findOperationBasePath (exported const)

getPathsWithOperations()

returns an array of all (absolute) paths containing operations

for a bundled project, that means /apps, /packages, /modules

for the OS project, that means /operations/tools and /operations/niches

Input
config (optional)	{ manualProjectRoot?: string, }
Output	string[]

📄 getPathsWithOperations (exported const)

returns an array of all (absolute) paths containing operations

for a bundled project, that means /apps, /packages, /modules

for the OS project, that means /operations/tools and /operations/niches

getSrcRelativeFileId()

returns a file id (path without extension) relative to the src folder of an operation

e.g. "general" for src/general.ts

NB: assumes all src is in the src folder

NB: removes "/" in the beginning, if found

Input
operationRelativePath	string
Output

📄 getSrcRelativeFileId (exported const)

returns a file id (path without extension) relative to the src folder of an operation

e.g. "general" for src/general.ts

NB: assumes all src is in the src folder

NB: removes "/" in the beginning, if found

getOperationClassification()

Returns

OperationClassification

Possible values

FULL STACK

cjs: only js (no node) (well, ts of course, but it gets built into common js)
ts: non-built typescript code (needs to be transpiled, not recommended)

TODO: esm: builds to ESM module resolved Javascript

FRONTEND ONLY (cannot be used within backend-only operations)

ui-web: has next.config.js and thus exposes something on some port when it is ran. next.js + react-based...
ui-app: uses react-native and exposes something on some port when it is ran
ui-ts: uses react (with (native)), which main entry points to typescript es6 files (this ui package cannot be built, should be transpiled. Primarily used for big ui libraries tied to a ui-web and ui-app for convenience. For other things, it is highly discouraged, please use ui-cjs or ui-esm)
ui-cjs: ui which main entry points to javascript es5 files (this ui package can be built). don't import ESM packages in here, this may give problems.
ui-esm: ui which builds to ESM module resolved Javascript. All packages that use ui-esm packages, need to be ui-esm, ui-es6, ui-web, or ui-app in order to work properly. It seems to have difficulties using this in ui-cjs

BACKEND ONLY (cannot be used within frontend-only operations)

node-cjs: includes other node packages, operations, core-imports, and globals.

TODO: node-esm: Typescript package that is built to ESM Javascript which also includes all node packages, operations, core-imports and globals.

TODO: node-ts: transpilable node package

server-cjs: exposes something on some port when it is ran and uses node code

Indexation

Operations will be classified automatically. It is good to remember that:

It will be classified as UI if isUiOperation resolves to true
It will be classified as Node if Operation has a (dev)dependency on @types/node.
Otherwise, it will be classified as base typescript (full stack)
It will be classified to an ESM operation if tsconfigCompilesEsm resolves to true.
It will be classified to a TS operation if packageCompilesTs resolves to true
In order for it to be classified as a server, you must set isNodeServer to true in the operation config object of Operation

OperationClassification if it's an operation, or undefined if it's not

NB: don't confuse this with

ImportClassification

node: node core packages like fs and path

react: react standard packages like react, react-native, expo, react-dom, etc.

package: packages from npm that are not classified as operations

operation: operations from our monorepo

internal: imports from other places in the same operation

NB: don't confuse this with OperationClassification

ImportClassification

Input
folderPath	string
Output

isBundle()

Input
folderPath (optional)	string
Output	{ }

📄 getOperationClassification (exported const)

Returns

OperationClassification

Possible values

FULL STACK

cjs: only js (no node) (well, ts of course, but it gets built into common js)
ts: non-built typescript code (needs to be transpiled, not recommended)

TODO: esm: builds to ESM module resolved Javascript

FRONTEND ONLY (cannot be used within backend-only operations)

ui-web: has next.config.js and thus exposes something on some port when it is ran. next.js + react-based...
ui-app: uses react-native and exposes something on some port when it is ran
ui-ts: uses react (with (native)), which main entry points to typescript es6 files (this ui package cannot be built, should be transpiled. Primarily used for big ui libraries tied to a ui-web and ui-app for convenience. For other things, it is highly discouraged, please use ui-cjs or ui-esm)
ui-cjs: ui which main entry points to javascript es5 files (this ui package can be built). don't import ESM packages in here, this may give problems.
ui-esm: ui which builds to ESM module resolved Javascript. All packages that use ui-esm packages, need to be ui-esm, ui-es6, ui-web, or ui-app in order to work properly. It seems to have difficulties using this in ui-cjs

BACKEND ONLY (cannot be used within frontend-only operations)

node-cjs: includes other node packages, operations, core-imports, and globals.

TODO: node-esm: Typescript package that is built to ESM Javascript which also includes all node packages, operations, core-imports and globals.

TODO: node-ts: transpilable node package

server-cjs: exposes something on some port when it is ran and uses node code

Indexation

Operations will be classified automatically. It is good to remember that:

It will be classified as UI if isUiOperation resolves to true
It will be classified as Node if Operation has a (dev)dependency on @types/node.
Otherwise, it will be classified as base typescript (full stack)
It will be classified to an ESM operation if tsconfigCompilesEsm resolves to true.
It will be classified to a TS operation if packageCompilesTs resolves to true
In order for it to be classified as a server, you must set isNodeServer to true in the operation config object of Operation

OperationClassification if it's an operation, or undefined if it's not

NB: don't confuse this with

ImportClassification

node: node core packages like fs and path

react: react standard packages like react, react-native, expo, react-dom, etc.

package: packages from npm that are not classified as operations

operation: operations from our monorepo

internal: imports from other places in the same operation

NB: don't confuse this with OperationClassification

ImportClassification

📄 isBundle (exported const)

getOperationRelativePath()

something like src/xxx/xxx/x.ts (no slash at start)

Input
absolutePath	string
Output

📄 getOperationRelativePath (exported const)

something like src/xxx/xxx/x.ts (no slash at start)

getOperationClassificationObject()

Input
-
Output

getOperationPathParse()

get all operation-related path information that can be inferred from the path

NB: currently it also looks up the operation name from its packagejson

Input
absolutePath	string
Output

getPathParse()

gets all kinds of information that can be inferred from any path (file or folder).

Input
absolutePath	string
Output	{ relativePathFromProjectRoot: string, }

📄 getOperationClassificationObject (exported const)

📄 getOperationPathParse (exported const)

get all operation-related path information that can be inferred from the path

NB: currently it also looks up the operation name from its packagejson

📄 getPathParse (exported const)

gets all kinds of information that can be inferred from any path (file or folder).

getRelativeLinkPath()

returns a relative link between two files

Input
absoluteFromFilePath	string
Output	`String`

getSubExtensions()

Input
absolutePath	string
Output	string[]

isOperation()

Checks whether or not an absolute path contains an operation. The only check it's doing is that the folder must contain both a package.json as well as a tsconfig.json

Input
absoluteFolderPath	string
Output	{ }

🔹 OperationClassificationObject

📄 getRelativeLinkPath (exported const)

returns a relative link between two files

📄 getSubExtensions (exported const)

📄 isOperation (exported const)

Checks whether or not an absolute path contains an operation. The only check it's doing is that the folder must contain both a package.json as well as a tsconfig.json

Tests

Show test information(2)

test()

Input
-
Output

📄 test (unexported const)

Internal

Show internal (24)

findFolderWhereMatch()

recursive. goes up a folder until it finds a package.json

Input
-
Output	{ folderPath: string, matchResult: { }, }

findOperationBasePathWithClassification()

recursive. goes up until it finds a folder that's an operation

because it had to read the package.json anyway, it's returning the operation classification as well

Input
startPath	string
Output	{ folderPath: string, classification: { }, }

getAllPackageJsonDependencies()

Input
operation	Operation Model for `typerepo` operations. Stored in `package.json` in every package (compatible with regular npm package.json data structure). An `Operation` is a NPM Package that applies the `typerepo` convention. TODO: add a validation to package.json files for the whole project, to ensure i can apply `fs-orm` convention Operation
Output	string[]

getCommonAncestor()

Finds the common ancestor for two absolute pahts

Input
path1	string
Output	`String`

getRelativePath()

gets the relative path from a specified root

will start with "/"

Input
absolutePath	string
Output

hasDependency()

Input
operation	Operation Model for `typerepo` operations. Stored in `package.json` in every package (compatible with regular npm package.json data structure). An `Operation` is a NPM Package that applies the `typerepo` convention. TODO: add a validation to package.json files for the whole project, to ensure i can apply `fs-orm` convention Operation
Output