False positive on `as const`

[tylerlaprade]

I did not expect this line to trigger this rule when allowConstantExport is enabled.

export const MENU_WIDTH = 232 as const;

When I remove as const, the rule doesn't trigger.

[ArnaudBarre]

"as const" is not needed for primitive. Is there a reason you are adding it?

[ArnaudBarre]

I fixed it because anyway this will be supported once the code is re-written to better handle nested cases (satisfies expression, multiple hoc, ...)

[AlokTakshak]

@ArnaudBarre
Can we add support for others Like ArrayExpression in the rule. Currently we have lots of files which have Array expression export along with others like enums etc from constants file and we are getting errors for those.
Shouldn't this be allowed using allowConstantExport as all these are just constant expressions

example: https://stackblitz.com/edit/vitejs-vite-v62lblbx?file=src%2FApp.constants.tsx,package.json&terminal=dev

[ArnaudBarre]

This is not easy to draw the line difference between an array that will never change and one that can be mutated later. If we decide it's ok to have export const Foo = [1, 2], after an hmr update, if one component do Foo.push(3), then if you try to log it somewhere outside of the file, you would still see the initial version of the array.

In the long term rolldown will bring back more bundling into the dev mode of Vite, which will allow to avoid this kind of restrictions because modules won't to update that much in isolation, so that's also one reason I don't want to invest to much into adding more things for this (also because then it can be hard to have the runtime checks in Vite and the lint rule to warn for the same cases)

[tylerlaprade]

"as const" is not needed for primitive. Is there a reason you are adding it?

There are many possible reasons, one might be if you want your type system to prevent you from using any numbers of pixels that aren't multiples of 8. Although in this case I think we just added it to everything in the constants.ts file without much thought.