Library
@fluentui/react - all v8 packages
Current Behaviour
While implementing #16976 I ran into following TS related(compile/runtime) bug within our packages.
target/lib tsconfig option restriction has effect on code that is used within monorepo package

Expected behavior:
I should get TS errors based on target/lib setting.
Why is this happening?
The issues starts within react-conformance package

- because we are using ES2015 features, those 2 functions will infer return type based on
node globals and thus will end up
with following output

- node types are explicitly importing ECMA2015+ libs from TS standard lib thus adding those to TS eval scope
Now because this, any API that is used from this package will "extend" (pollute) TS eval scope of particular package where it's being used (in our example react-menu)
👉 That's why we don't see any errors in our react-menu (event though we are using ECMA2015+ features)
Let's say we'd fix consoleUtil.ts (implementing Object.assign on our own for example), the main problem would not go away.
Why?
- if we briefly skim through
react-conformance implementation, we would discover that there is enzyme imported (within defaultTests.tsx
- now
enzyme types add cheerio types (/// <reference types="cheerio" />) and cherio types add node types (/// <reference types="node" />) so we end up with the same issue
Conclusion
Now even if we remove enzyme and other related culprits, nothing will stop us to introduce such a anomaly in future, because we are mixing 2 environments (with storybook in place 3) within 1 TS config, those leaks like this are inevitable.
An elegant solution for this problem was already introduced in (this RFC), - tsconfig per environment consolidated via TS Solution style config.
Also the solution in more detail: https://gist.github.com/Hotell/19e776aa1a47258340b8bd9b477ad303
Library
@fluentui/react- all v8 packagesCurrent Behaviour
While implementing #16976 I ran into following TS related(compile/runtime) bug within our packages.
target/libtsconfig option restriction has effect on code that is used within monorepo packageExpected behavior:
I should get TS errors based on target/lib setting.
Why is this happening?
The issues starts within
react-conformancepackagenodeglobals and thus will end upwith following output
Now because this, any API that is used from this package will "extend" (pollute) TS eval scope of particular package where it's being used (in our example
react-menu)👉 That's why we don't see any errors in our react-menu (event though we are using ECMA2015+ features)
Let's say we'd fix
consoleUtil.ts(implementing Object.assign on our own for example), the main problem would not go away.Why?
react-conformanceimplementation, we would discover that there isenzymeimported (withindefaultTests.tsxenzymetypes addcheeriotypes (/// <reference types="cheerio" />) andcheriotypes addnodetypes (/// <reference types="node" />) so we end up with the same issueConclusion
Now even if we remove
enzymeand other related culprits, nothing will stop us to introduce such a anomaly in future, because we are mixing 2 environments (with storybook in place 3) within 1 TS config, those leaks like this are inevitable.An elegant solution for this problem was already introduced in (this RFC), - tsconfig per environment consolidated via TS Solution style config.
Also the solution in more detail: https://gist.github.com/Hotell/19e776aa1a47258340b8bd9b477ad303