-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
bug: TypeScript target/lib option doesn't constraint ECMA features on type checking within packages #17101
Comments
@Hotell - Thanks for the feedback and suggestion. @khmakoto - would you be able to follow this one up ? I am not sure if you will need to include talks with @ecraig12345? |
What needs to be done:
|
This PR moves the descendants utility from `react-accordion` to `react-utilities` and adds inline polyfills because of type leakage in component packages from `react-conformance` (see microsoft#17101)
* Move descendants to react-utilities This PR moves the descendants utility from `react-accordion` to `react-utilities` and adds inline polyfills because of type leakage in component packages from `react-conformance` (see #17101) * Change files * undo tsconfig change
* Move descendants to react-utilities This PR moves the descendants utility from `react-accordion` to `react-utilities` and adds inline polyfills because of type leakage in component packages from `react-conformance` (see microsoft#17101) * Change files * undo tsconfig change
* Move descendants to react-utilities This PR moves the descendants utility from `react-accordion` to `react-utilities` and adds inline polyfills because of type leakage in component packages from `react-conformance` (see microsoft#17101) * Change files * undo tsconfig change
Because this issue has not had activity for over 150 days, we're automatically closing it for house-keeping purposes. Still require assistance? Please, create a new issue with up-to date details. |
Because this issue has not had activity for over 180 days, we're automatically closing it for house-keeping purposes. Still require assistance? Please, create a new issue with up-to date details. |
Because this issue has not had activity for over 180 days, we're automatically closing it for house-keeping purposes. Still require assistance? Please, create a new issue with up-to date details. |
Library
@fluentui/react
- all v8 packagesCurrent 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 packageExpected behavior:
I should get TS errors based on target/lib setting.
Why is this happening?
The issues starts within
react-conformance
packagenode
globals 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-conformance
implementation, we would discover that there isenzyme
imported (withindefaultTests.tsx
enzyme
types addcheerio
types (/// <reference types="cheerio" />
) andcherio
types addnode
types (/// <reference types="node" />
) so we end up with the same issueConclusion
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
The text was updated successfully, but these errors were encountered: