Skip to content
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

[core] Support public paths in module augmentation #24267

Merged
merged 2 commits into from
Jan 4, 2021

Conversation

eps1lon
Copy link
Member

@eps1lon eps1lon commented Jan 4, 2021

  1. Use public paths in module augmentation
  2. Test documented module augmentation /cc @mnajdova

We have a notion of what we consider "public paths". However, this does not apply to type imports which makes it harder to teach ("ok here, but not ok there"). Since we already make types public by documenting that the paths are public we might as well export them directly which means we can simplify how we teach public paths.

The existing patterns continue to work but are more likely to break during refactoring. The patterns we now document are tested in CI and therefore a lot more robust.

Implementation choices

separate script

  1. does not slow down test:unit
  2. Allows parallel testing (which we haven't set up for mocha)
  3. can be included in test suite that runs with TypeScript nightlies

@eps1lon eps1lon added package: material-ui Specific to @mui/material typescript labels Jan 4, 2021
@mui-pr-bot
Copy link

mui-pr-bot commented Jan 4, 2021

Details of bundle changes

Generated by 🚫 dangerJS against 8fc280b

@eps1lon eps1lon marked this pull request as ready for review January 4, 2021 13:49
Comment on lines +37 to +39
await Promise.all(
tsconfigPaths.map(async (tsconfigPath) => {
await test(tsconfigPath).then(
Copy link
Member

@oliviertassinari oliviertassinari Jan 4, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if running one process per test case in concurrence will scale well with the number of test cases. I don't know how TypeScript handles the requests internally. I don't think the scaling question is something we need to worry too much about now, as we don't yet have a large number of test cases. I was curious.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I haven't looked into the issue too much. There's a lot of wasted work by doing a full compilation just to test module augmentation. test_types isn't really a bottleneck at the moment but once it becomes one we might want to look into the issue a bit more. Right now I'm glad we have some tests for module augmentation in place.

@eps1lon eps1lon changed the title [core] Simplify module augmentation [core] Support public paths in module augmentation Jan 4, 2021
@eps1lon eps1lon merged commit 6f08247 into mui:next Jan 4, 2021
@eps1lon eps1lon deleted the feat/core/module-augmentation branch January 4, 2021 15:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
package: material-ui Specific to @mui/material typescript
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants