[Icon Request] nest-entity

[GabrielFreitasP]

Icon Type

• [ ] Folder
• [X] File

File Names

• nest-dto
• nest-entity

Graphic ideas Please refer to this icon and change the color to any color that does not already exist.

Additional context Many projects use the files file.dto.ts and file.entity.ts when using Nest.js.

[lucas-labs]

Although it's not exactly what you were asking for, you can achieve this by using the custom clones functionality.

You can now choose an icon you like and "clone it", assign it to the file extension or file name you want, while changing the color to any color you like, using the new custom clones feature in your vscode user settings (or workspace settings).

Usage example (click me to expand):

```jsonc // settings.json { // ... "material-icon-theme.files.customClones": [ { "base": "nest", "color": "lime-500", "fileExtensions": ["dto.ts"], "name": "nest-dto" }, ... ], // ... } ```

Result:

Does this suit your needs?

[mallowigi]

@lucas-labs True but this is a default that most nestjs users will be likely to use, so this should be in the defaults.

[lucas-labs]

@mallowigi I haven't used nestjs since a long time ago. Is there any other file naming convention that we are missing besides dto?

[PKief]

@lucas-labs @mallowigi There were some suggestions from @bart-krakowski in https://github.com/material-extensions/vscode-material-icon-theme/pull/1532. But to be honest, I don't think that we should have a nest icon for *.config.ts, *.util.ts, *.enum.ts, *.type.ts or *.interface.ts, as these files are still too generic, even in a Nest.js project.

[mallowigi]

@lucas-labs @PKief I am a NestJS expert so in my project I have a "NestJS Pack" like you do, in which I reference the following extensions:

• .adapter.ts (Adapter services)
• .args.ts (GraphQL Args)
• .commands.ts (CQRS commands)
• .config.ts (Specific Nest Config services)
• .controller.ts
• .constants.ts (generic constants but blends well within
• .cron.ts/.task.ts (for Cron tasks)
• .decorator.ts (Nest Decorators)
• .dto.ts (NestJS DTO)
• .e2e.ts (end to end tests)
• .entity.ts (for TypeORM/MikroORM/Prisma etc)
• .filter.ts (Nest Exception Filters)
• .gateway.ts (Websockets gateways)
• .gql.ts/graphql.ts (GraphQL queries/mutations)
• .guard.ts (NestJS Guards)
• .input.ts (GraphQL inputs)
• .interceptor.ts (Nest Interceptors)
• .interface.ts (Generic interface but blends well within a NestJS project rather than the generic TypeScript icon)
• .listener.ts (For PubSub pattern)
• .loader.ts (GraphQL Dataloaders)
• .middleware.ts
• .model.ts (First world entities, different from ORM entities that contain business logic)
• .module.ts
• .pipe.ts (NestJS Pipes)
• .processor.ts (rarely used)
• .provider.ts (data providers)
• .queue.ts (Bull queues)
• .repository.ts (ORM repositories)
• .resolver.ts (GraphQL resolvers)
• .scalar.ts (GraphQL scalars)
• .schema.ts (Zod Schemas)
• .service.ts
• .strategy.ts (Passport strategies)
• .subscriber.ts (PubSub)
• .types.ts (generic typescript types but blends well within a NestJS project rather than the generic TypeScript icon)
• .utils.ts (generic utils but blends well...)

As you can see one of the great things in Nest is the separation of concerns of everything. Therefore having the same icons but with different colors helps greatly during NestJS development.

Here's an example in our project:

I agree that a lot of these extensions are related to a "flavor" of NestJS projects. Not all NestJS projects use GraphQL, Passport, Zod or Bull. But in general if the NestJS pack is on, it's a great idea to group everything Nest related within the default bundles rather than have all developers define their own associations.