# cool-admin-midway: a backend scaffold whose typeorm dependency is a pinned fork and whose default password is 123456

> This is an application template rather than a library, marked private in its own package file, that builds CRUD endpoints from a decorator and lets the ORM create tables at startup. Its defaults are tuned for a laptop: a root database account with the password 123456, a Redis with no password, and a Docker image that deletes its own lockfile.

**cool-team-official/cool-admin-midway** — 🔥 cool-admin(midway版)一个很酷的后台权限管理框架，Ai编码、流程编排、模块化、插件化、CRUD极速开发，永久开源免费，基于nodejs、typescript、typeorm、mysql、jwt、vue3、vite、element-ui等构建

- Repository: https://github.com/cool-team-official/cool-admin-midway
- Website: https://cool-js.com
- Stars: 3,277 · Forks: 736
- Language: TypeScript
- License: NOASSERTION
- Published: 2026-09-24 · Updated: 2026-09-24 · Language: en
- Canonical page: https://hysenlabs.com/projects/cool-team-official-cool-admin-midway

## The dependency called typeorm is a fork pinned to one version

One line in the dependency list does something worth reading twice:

```
"typeorm": "npm:@cool-midway/typeorm@0.3.20",
```

An npm alias means the import name and the installed package are different things. Code writes typeorm, the resolver installs a package whose real name is @cool-midway/typeorm, and the version is pinned to exactly 0.3.20 with no range. Anyone auditing this project by dependency name, any lockfile review and any question of the form whether the ORM is current all have to look past the name. The rest of the list follows a different convention, with caret ranges on the Midway packages pinned together at 3.20.3, jsonwebtoken at 9, axios at 1.8 and mysql2 at 3.14. So one dependency in a tree of ranges is frozen to a fork, and it is the one every query in the application goes through.

## The database password is 123456 and both ports are published

The compose file is offered as the local database environment and it starts two containers with credentials in plain text. MySQL is started with its native password plugin, a strict SQL mode, and a group_concat limit raised to 102400, with these settings:

```
MYSQL_ROOT_PASSWORD: "123456"
MYSQL_DATABASE: "cool"
MYSQL_USER: "root"
MYSQL_PASSWORD: "123456"
```

The ports are then mapped to the host, 3306 for the database and 6379 for Redis, on a named network with restart always. Redis has no password at all, which is a deliberate choice rather than an oversight: the line that would require one is present in the file and commented out. The same password shows up in the application configuration, where the data source connects to 127.0.0.1 on 3306 as root with password 123456 against a database named cool, and in the demo credentials published for the demo site, where the account is admin and the password is 123456. Every default in the stack is a development default, and none of them is marked as such in a place a deployer would necessarily look.

## synchronize: true ships with its own warning about data loss

The data source block carries a comment that is worth reading as documentation rather than as reassurance:

```ts
        // 自动建表 注意：线上部署的时候不要使用，有可能导致数据丢失
        synchronize: true,
```

Automatic table creation is on, and the note says not to use it online because it can lose data. The rest of the block is equally explicit about being a development posture: logging off, cache on, and an entity path of **/modules/*/entity, which means any file placed in a module's entity directory is picked up as a table definition. That is also the mechanism behind the quick start, where a new table is created by adding a file at src/modules/demo/entity/goods.ts and starting the server, with no SQL to write. The convenience and the warning are the same switch, so a deployment that forgets to flip it inherits both the convenience and the data loss.

## The container build deletes the lockfile before installing for production

The Dockerfile installs dependencies twice, and between the two installs it throws away the things that would make them reproducible:

```
RUN npm install
COPY . .
RUN npm run build
RUN rm -rf node_modules && rm package-lock.json
RUN npm install
```

The first install exists only so the build has its toolchain, the copy brings in the source including the lockfile the repository ships, and then both the installed tree and the lockfile are deleted before the final install. The consequence is that the production layer resolves fresh versions from the registry rather than the versions that were built against. Two other choices in the same file matter for an audit: the Alpine package sources are rewritten with sed to point at a mirror, and npm is pointed at a different registry than the default, both of which change where bytes come from without changing what is written down. The final image exposes 8001 and starts through npm run start, so the process runs under npm rather than node directly.

## The dev script deletes a source file every time it starts

The development command begins by removing something from the source tree:

```
"dev": "rimraf src/index.ts && cool check && cross-env NODE_ENV=local mwtsc --cleanOutDir --watch --run @midwayjs/mock/app.js --keepalive"
```

So a source file is deleted, then a command named cool check runs, and only then does the TypeScript watch process start. Whatever cool check produces is what replaces the removed file, which means src/index.ts is treated as generated output rather than as something you edit, and a developer who put code in it would find it gone on the next run with no warning in the script itself. The production path is separate and simpler: start runs bootstrap.js with NODE_ENV set to production, which is the one command the container uses. Testing and style are separate too, with jest for tests and mwts for lint and lint:fix, and the project asks for Node 18 or newer with TypeScript around 5.8.

## Tenant isolation is one globally injected query condition

Multi-tenancy is listed among the features with a single sentence of mechanism: the query condition is injected globally and dynamically. That design has one clear consequence, which is that isolation is not declared at the call site. Where every read passes through the layer that performs the injection, the condition is applied without anyone remembering it; where a query is built by hand, or a raw statement is issued, the same guarantee does not come for free, because nothing in that code path asked for it. The document links out for the details rather than describing the failure modes, so a reviewer has to read the implementation to know which paths are covered. The same pattern of a global mechanism is used for internationalisation, which is described as automatic translation by a language model with no change to the original code.

## The AI coding feature depends on a model this repository does not carry

The first feature in the list is AI coding, and the description says it works by fine-tuning a large model on the framework's own idioms so that a simple feature can be generated from the API interface through to the frontend page in one step. That is a training pipeline, and none of it is in this repository: the repository is the application, its entity files, its controllers and its configuration, and the link for the feature points at the documentation site. What the repository does carry for tooling is a cursorrules file and a cursor directory at the root, alongside editorconfig, eslint and prettier configuration, which are instructions for an assistant rather than a model. So the headline capability depends on something an adopter has to obtain separately, and the repository's own contribution to it is the conventions an assistant should follow.

## The default branch is 8.x while the badge link points at master

The repository is checked out from a branch named 8.x, and the package file says version 8.0.0 with private set to true, which is why there is nothing to publish and no release history. The versioning that matters is in the dependencies instead, where the framework packages carry 8.0 ranges and the Midway packages sit at 3.20.3. Against that, the licence is unresolved: no licence identifier is recorded, a LICENSE file does sit at the root, and the text describes the project as open source and free. The documentation links in the project file point at master, which is no longer the default branch, so a licence link copied from the readme lands on a branch that is not the one being served. None of that blocks adoption, but each of the four facts is the kind that gets discovered later rather than at install time.

## Conclusion

Use it as a starting point for an internal admin tool and treat every default as something to change before it meets a network. Three checks come before that. The dependency called typeorm is not upstream TypeORM but a fork aliased under that name and pinned to a single version, so a dependency audit reading typeorm is reading the wrong package. The database configuration ships synchronize enabled with its own warning about data loss in production, and the compose file publishes both database ports to the host with a root password of 123456 and no Redis password at all. And the container build deletes node_modules and package-lock.json between the two installs, which means the image that runs is assembled without a lockfile and can differ from what was tested.

## FAQ

### Which database does cool-admin-midway use by default?

MySQL, with 5.7 as the floor and 8.0 recommended, driven through a TypeORM data source whose type is set to mysql. PostgreSQL and SQLite are named as supported alternatives. The shipped configuration connects to 127.0.0.1 on port 3306 as root with the password 123456 against a database named cool.

### How do you run cool-admin-midway locally?

Edit the database configuration in src/config/config.local.ts, then run npm i followed by npm run dev, and open http://localhost:8001/. Node 18 or newer is required. The dev script removes src/index.ts, runs a cool check command, then starts the TypeScript watch process; the test suite runs under jest and the lint script is mwts check.

### What does the cool-admin-midway Dockerfile do with dependencies?

It runs npm install before the build to get the toolchain, copies the source, builds, then deletes both node_modules and package-lock.json and runs npm install again for the runtime. The final image therefore resolves fresh versions rather than the ones that were built against, and the image rewrites the Alpine package sources to a mirror and points npm at a different registry.

### Does cool-admin-midway create database tables automatically?

Yes, through the synchronize option in the data source, which the configuration annotates with a warning not to use online because it can lose data. Entity files placed under a module's entity directory are picked up automatically, so a new table comes from adding a file such as src/modules/demo/entity/goods.ts and starting the server.

## Sources

- [cool-team-official/cool-admin-midway on GitHub](https://github.com/cool-team-official/cool-admin-midway)
- [Issues](https://github.com/cool-team-official/cool-admin-midway/issues)
- [Project website](https://cool-js.com)
- [README](https://github.com/cool-team-official/cool-admin-midway/blob/8.x/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/cool-team-official-cool-admin-midway