-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
[core] Avoid node
types in the built packages
#17533
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
Conversation
@@ -8,7 +8,9 @@ | |||
"noEmit": false, | |||
"emitDeclarationOnly": true, | |||
"outDir": "build/esm", | |||
"rootDir": "./src" | |||
"rootDir": "./src", | |||
"skipLibCheck": true, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Without this compilation failed due to not finding node
types in the exceljs
lib.
I don't think it's that important to check this validity twice (typescript
step already checks with node
types defined).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But our users' compilation would fail as well, right? Is this the issue?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, if I remember correctly, that's the actual issue. 👍
I think it shouldn't affect our end users, should it?
If they have node
types in their config, it's going to be fine, if they don't - it's going to error out. 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They would have exceljs
as a transitive dependency, and potentially not have @types/node
defined in their env. I'd expect it to error on their end if they have skipLibCheck
set to false (which I'd encourage).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, in this case, they would already be getting this error with the current setup. 🤔
Or am I missing something? 🤷
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well yes, they'll be getting this error, but because our own package mandates it as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, sadly, we depend on a stale package that is causing multiple issues. 🙈
Deploy preview: https://deploy-preview-17533--material-ui-x.netlify.app/ |
@@ -14,7 +14,7 @@ export class TimerBasedCleanupTracking implements CleanupTracking { | |||
|
|||
register(object: any, unsubscribe: UnsubscribeFn, unregisterToken: UnregisterToken): void { | |||
if (!this.timeouts) { | |||
this.timeouts = new Map<number, NodeJS.Timeout>(); | |||
this.timeouts = new Map<number, ReturnType<typeof setTimeout>>(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Given that we need specificity to have conclusive types, I would vote for reverting mui/mui-public#195 and using window.setTimeout
with return type of number
instead of relying on terse ReturnType<typeof setTimeout>
, which would now return NodeJS.Timeout
in IDE/JSDoc and number
in built output.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This makes perfect sense ... I was wondering why we use it without the window
prefix as well at some point
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
window and global/globalThis are different things and can be misleading. I think that is the main argument to not use things from window
which are usually present in global
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why would IDE's keep returning NodeJS.Timeout
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because setTimeout
exists on Node
and in regular (not build) tsconfig
, we list the node
types to make linting happy (we use some node APIs in tests and scripts)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
in principle for code that runs on different environments you write different tsconfig files. I don't think they necessary need to be separate packages. Our current build tools wouldn't work with it though
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That is what we have now more than before this PR.
In IDE and typechecking, we use the tsconfig.json
file, while type building relies on the tsconfig.build.json
file. 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mean multiple tsconfig files that each include different parts of the code. Like e.g. the vite example where vite config has node types included and src doesn't.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Janpot, I get the idea. 👍
I have briefly explored your idea:
- "app"
tsconfig
targeting the source files and excluding the test files - "test"
tsconfig
targeting the whole project
But then there are issues about unresolved@mui/x-internals
package imports. 🙈 🤷
Here is the diff that I've been trying out on @mui/x-charts
package:
diff --git a/packages/x-charts/package.json b/packages/x-charts/package.json
index 28d0d761c5..53084fed97 100644
--- a/packages/x-charts/package.json
+++ b/packages/x-charts/package.json
@@ -24,7 +24,7 @@
"charts"
],
"scripts": {
- "typescript": "tsc -p tsconfig.json",
+ "typescript": "tsc -b",
"build": "pnpm build:node && pnpm build:stable && pnpm build:types && pnpm build:copy-files",
"build:node": "node ../../scripts/build.mjs node",
"build:stable": "node ../../scripts/build.mjs stable",
diff --git a/packages/x-charts/tsconfig.app.json b/packages/x-charts/tsconfig.app.json
new file mode 100644
index 0000000000..a8dc1124e0
--- /dev/null
+++ b/packages/x-charts/tsconfig.app.json
@@ -0,0 +1,10 @@
+{
+ "extends": "./tsconfig.json",
+ "compilerOptions": {
+ "composite": true,
+ "types": ["../../extends.d.ts", "@mui/material/themeCssVarsAugmentation"],
+ "skipLibCheck": true
+ },
+ "include": ["src/**/*"],
+ "exclude": ["src/**/*.test.*", "src/**/*.spec.*"]
+}
diff --git a/packages/x-charts/tsconfig.json b/packages/x-charts/tsconfig.json
index a31f6f717c..173a7687e2 100644
--- a/packages/x-charts/tsconfig.json
+++ b/packages/x-charts/tsconfig.json
@@ -1,14 +1,5 @@
{
"extends": "../../tsconfig.json",
- "compilerOptions": {
- "types": [
- "@mui/internal-test-utils/initMatchers",
- "@mui/material/themeCssVarsAugmentation",
- "chai-dom",
- "mocha",
- "node"
- ],
- "skipLibCheck": true
- },
- "include": ["src/**/*", "../../test/utils/addChaiAssertions.ts"]
+ "references": [{ "path": "./tsconfig.app.json" }, { "path": "./tsconfig.test.json" }],
+ "files": []
}
diff --git a/packages/x-charts/tsconfig.test.json b/packages/x-charts/tsconfig.test.json
new file mode 100644
index 0000000000..317c39c264
--- /dev/null
+++ b/packages/x-charts/tsconfig.test.json
@@ -0,0 +1,15 @@
+{
+ "extends": "./tsconfig.json",
+ "compilerOptions": {
+ "composite": true,
+ "types": [
+ "@mui/internal-test-utils/initMatchers",
+ "@mui/material/themeCssVarsAugmentation",
+ "chai-dom",
+ "mocha",
+ "node"
+ ],
+ "skipLibCheck": true
+ },
+ "include": ["src/**/*", "../../test/utils/addChaiAssertions.ts"]
+}
Do you know what I could be missing? 🤔
In any case, I think it could be left for a follow-up, don't you agree? 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, absolutely
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM ... but for this I would wait for a second review
Fixes #17477.
Removing the usage of
node
in thetsconfig.compilerOptions.types
to avoidNodeJS
types in the built packages.The drawback of this approach is inconclusive JSDoc/IntelliSense.
Hovering over methods shows
node
JSDoc where available, while the built output will have a different API (i.e.setTimeout
).I don't know how to easily avoid having
node
types in the project config, since there are numerous usages ofpath
,__dirname
and similar things, especially in test files.