Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
LPS-130359 Work around value visibility issue
As noted in this issue: microsoft/TypeScript#37888 And specifically in my comment: microsoft/TypeScript#37888 (comment) There is a problem in the TypeScript compiler involving indirect references to unique Symbol types defined in projects connected by via project references. In short, `frontend-js-state-web` uses private `Symbol` instances as an implementation detail, and these wind up in the type declaration files as, eg: declare const ATOM: unique symbol; So, when another project attempts to use a function like `Liferay.State.atom()` that returns an object of a type involving that symbol, TS may complain with: TS4023: Exported variable 'blah' has or is using name 'ATOM' from external module "path/to/State" but cannot be named. The exact conditions required to trigger this are subtle, because using `atom()` is working fine in places like the `frontend-js-react-web` tests. My theory is that those work fine because the uses are all internal, so TS doesn't need to emit any type information involving the symbol. But in the case of `item-selector-taglib`, which I am working on for the purposes of this LPS, I have to export the atom, and that's when the error pops up. Remove the `export` and there is no error. So the problem is that TS has to emit a `.d.ts` file and it can't, because it can't "see" the value of the symbol in the consuming module. We can make the error go away like I am here in this commit, switching from a symbol to a plain old string. These objects are read-only and cannot be manipulated directly, so this is going to be fine, although I did like the way the symbol keys were "invisible" from the outside.
- Loading branch information