-
Notifications
You must be signed in to change notification settings - Fork 2.9k
Description
Library
@fluentui/react - all v8 packages
Current 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 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
nodeglobals 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-conformanceimplementation, we would discover that there isenzymeimported (withindefaultTests.tsx - now
enzymetypes addcheeriotypes (/// <reference types="cheerio" />) andcheriotypes addnodetypes (/// <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


