-
Notifications
You must be signed in to change notification settings - Fork 304
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
More tree shaking #10355
More tree shaking #10355
Conversation
@@ -87,7 +87,7 @@ const config = { | |||
} | |||
] | |||
}, | |||
externals: ['vscode', 'commonjs', 'electron'], // Don't bundle these | |||
externals: ['vscode', 'commonjs', 'electron', 'moment'], // Don't bundle these |
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.
Is it possible to do something to prevent we don't end up in a situtation where tomorrow we pull in a 3rd party package or an existing 3rd party package ends up pulling in moment, then things will not work, or it will fail only in certian cases based on where and how the 3rd party package ends up using moment.
E.g. can we write up a linter to look at package-lock.json and ensure that nothing ever pulls in moment except for jupyter. Else I feel this is a risky change (as mentioned if some other package pulls it in, then things could break sometimes)
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.
Good 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.
Would like to ensure no other package pulls in moment, if they do, then we'd need to review that separately. Else we end up in a situation where something could break in the future.
Thanks @DonJayamanne for the suggestion, we should validate the dependencies to see if any new package we use load Added a gulp task to validate the lock file and added it to the pre-commit hook. |
.husky/pre-commit
Outdated
@@ -15,4 +15,5 @@ if [ -z "$changed" ]; then | |||
fi | |||
|
|||
npm run generateTelemetry | |||
npm run validateDependencies |
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.
Can we maybe do this in the linter step for the build? I'm wary of adding yet more stuff to pre-commit. Pre-commit already takes like 60 seconds for me.
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.
@rchiodo 👍 I dislike slow commit, 60 seconds is too much. I'll move it to the linter since we always do PR.
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.
Can we maybe do this in the linter step for the build? I'm wary of adding yet more stuff to pre-commit. Pre-commit already takes like 60 seconds for me.
This is why I don't like the pre-commit hooks - slows down my workflow, fortunately the formatting pre-commit hook doesn't work for me.
Codecov Report
@@ Coverage Diff @@
## main #10355 +/- ##
=====================================
- Coverage 64% 64% -1%
=====================================
Files 212 212
Lines 9557 9559 +2
Branches 1527 1530 +3
=====================================
- Hits 6162 6151 -11
- Misses 2924 2927 +3
- Partials 471 481 +10
|
Re #10307
moment
as external since we are not using it (neither doesjupyterlab/services
)rxjs
sub modules onlypackage-lock.json
has been regenerated by runningnpm install
(if dependencies have changed).