How to use the same custom decorator between custom emitters?

[jceipek]

TypeSpec has built-in, unnamespaced decorators like @minValue for which individual emitters can define different behavior. How can I make a similarly unnamespaced decorator @myCustomDecorator so that multiple emitters can make use of the same invocation like the following?

@myCustomDecorator("some payload")
model SomeModel {
  some_field: safeint
}

What I've Tried

When I do:

import "../my-emitter1"; // Get access to @myCustomDecorator for my-emitter1
import "../my-emitter2"; // Get access to @myCustomDecorator for my-emitter2

@myCustomDecorator("some payload")
model SomeModel {
  some_field: safeint
}

I get:

> tsp compile main.tsp --config tspconfig.yaml

TypeSpec compiler v0.56.0

Diagnostics were reported during compilation:

/some_path/my-emitter1/lib/main.tsp:9:12 - error duplicate-symbol: Duplicate name: "@myCustomDecorator"
> 9 | extern dec myCustomDecorator(target: Model, payload: valueof string);
    |            ^^^^^^^^^^^^^^^^^
/some_path/my-emitter2/dist/src/index.js:1:1 - error duplicate-symbol: Duplicate name: "@myCustomDecorator"
> 1 |
    | ^
/some_path/my-emitter2/lib/main.tsp:9:12 - error duplicate-symbol: Duplicate name: "@myCustomDecorator"
> 9 | extern dec myCustomDecorator(target: Model, payload: valueof string);
    |            ^^^^^^^^^^^^^^^^^
/some_path/my-emitter2/lib/main.tsp:9:12 - error missing-implementation: Extern declaration must have an implementation in JS file.
> 9 | extern dec myCustomDecorator(target: Model, payload: valueof string);
    |            ^^^^^^^^^^^^^^^^^

Found 4 errors.

If I name one of the decorators differently, like myCustomDecorator2, I can do this:

import "../my-emitter1"; // Get access to @myCustomDecorator for my-emitter1
import "../my-emitter2"; // Get access to @myCustomDecorator2 for my-emitter2

@myCustomDecorator("some payload")
@myCustomDecorator2("some payload")
model SomeModel {
  some_field: safeint
}

without any issues. However, I'd like to use the same custom decorator invocation for all my custom emitters, just like I can with built in decorators like @minValue.

Additional Context

I create custom unnamespaced decorators using the following 3 steps, inspired by what I've seen in https://github.com/tjprescott/typespec-pydantic, but without namespacing:

1. Define it in a lib/main.tsp like so:

import "../dist/src/index.js";

using TypeSpec.Reflection;

extern dec myCustomDecorator(target: Model, payload: valueof string);

2. Export a $myCustomDecorator(context: DecoratorContext, entity: Model, payload: string) function via ../dist/src/index.js, based on eg https://github.com/tjprescott/typespec-pydantic/blob/main/packages/typespec-pydantic/src/decorators.ts and https://github.com/tjprescott/typespec-pydantic/blob/main/packages/typespec-pydantic/src/index.ts
3. Add "tspMain": "lib/main.tsp", to package.json

[timotheeguerin]

A few things:

1. I would recommend against using any unamespace types at all in your libraries, this increase the chance of conflict when importing the library which cannot be resolved.
2. Either way the namespace where the decorator is defined doesn't change this. A decorator can only be defined one in the same scope. The way it works for @minvalue is the decorator and its implementation are in the compiler. Emitters do not change the implementation of the decorator they can just consume the getMinValue function to retrieve the data set by the decorator.

With this in mind you should most likely create a common.tsp file/library where you define those decorators. And this is what you import in your spec. Then each emitter can retrieve the data saved by the decorator and treat it however it sees fit.
For example we have this pattern with the @typespec/openapi library which has some decorator applicable to openapi3 and openapi2 https://github.com/microsoft/typespec/blob/main/packages/openapi/lib/decorators.tsp and then the openapi3 emitter and our internal azure openapi2 emitter can use the same decorator

[jceipek]

I got it to work with a shared library. Thanks for your help!

[bterlson]

Just to make a pedantic point that is not at all germane but documenting it in case it helps others in the future...

TypeSpec's decorators aren't un-namespaced, they're in the TypeSpec namespace. It's just that every source file has an implicit using TypeSpec; in it. This might become important if you have something that conflicts with a type in the TypeSpec namespace and need to disambiguate with a fully-qualified name (e.g. use TypeSpec.minValue if another library you're using exposes a minValue decorator for some reason).