Open ColinEberhardt opened 3 years ago
It's problem of TypeScript and prettier, they both don't support top-level decorators
It's problem of TypeScript and prettier, they both don't support top-level decorators
Agreed, but it is also a problem for AssemblyScript developers ;-)
In one case, it results in compilation errors that are not easy to understand, and in the other, it renders the tool unusable. It would be good to consider potential options that remove this friction.
The only thing what we can do is implementing our own language server: https://github.com/Shopify/asls
For now you could add // @as-ignore: decorator
one line below inline decorator which hide TS error. But not affect to prettifier unfortunately
OK, that sounds like a big job! Considering how close AS is to TS, it is a shame that these small differences cannot be accommodated with the TS tooling directly.
What's wrong with ESLint? Does it not perform as well as prettier? I've found it supports decorators fine and is what the main project uses.
This has recently been mentioned in Discord, and there was the idea to introduce a comment-like alternative, say /*! @inline */
that is only interpreted as being part of the code by asc
. Could even be extended to a general concept for actual code, not just decorators. It's more a hack, sadly, but perhaps that'd be useful? If not, I guess the alternatives are to not use decorators on functions in code that is meant to the portable, like the compiler itself does, or try to advocate for our use case in the tooling we rely on, or wait for actual function decorators to become a thing, if ever.
I like this idea because it open opportunity implement more DSL-like annotations like doc-testing for example
I like the idea of
// @ts-ignore: decorator
@lazy const x: u32 = 0;
Becoming
// @lazy
const x: u32 = 0;
I very much like that idea as it would allow me to use some familiar and powerful tooling for my AS projects
What's wrong with ESLint?
ESlint is a different type of tool, it’s focus is on linting, i.e. enforcing specific coding styles to create more safe and consistent code. Prettier is a formatter.
there is some overlap between the two, however, people often use both together.
Yes, I would really love it if we could turn decorators into the comment-format... It would be great!
This has recently been mentioned in Discord, and there was the idea to introduce a comment-like alternative, say /! @inline / that is only interpreted as being part of the code by asc. Could even be extended to a general concept for actual code, not just decorators. It's more a hack, sadly, but perhaps that'd be useful?
Adding a further note - when running AS as TS (as per the portability instructions), these function decorators also cause problems:
TSError: ⨯ Unable to compile TypeScript:
assembly/tz/rule.ts:3:1 - error TS1206: Decorators are not valid here.
Another reason why comment-style alternatives would be useful.
bump keeping this issue open 😊
any updates?
any updates?
Actually not. @dcodeIO @MaxGraey @CountBleck WDYT? I think supporting comment-style decorator is helpful to reuse infrastructures in TS for example linter and formatter.
What I've wondered so far was how we'd annotate these. Imagine
// @inline
which could just be a commented out decorator in development, and we'd not want to recognize it as a decorator in this case. We'd need some format to indicate that this is intentional I guess.
Maybe something as simple as a space after the @
or a triple slash could indicate "commented" decorators.
I agree triple slash. Just like reference in TS
Maybe we shouldn't change anything, just wait for this new proposal: https://github.com/tc39/proposal-function-and-object-literal-element-decorators
The use of function decorators results in a TS compiler error,
Decorators are not valid here
.It also prevents the use of tools such as Prettier to format the code.