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

chore: Bundle the extension using esbuild #421

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

cwahbong
Copy link
Contributor

@cwahbong cwahbong commented Oct 20, 2024

This should not affect the existing build and test flow, but adding an additional step right before building vsix package.

The esbuild.js is copied from VSCode extension generator template then format fixed by prettier.

This reduces the package size from ~5MB -> ~250KB.

@cwahbong cwahbong changed the title Bundle the extension using esbuild chore: Bundle the extension using esbuild Oct 20, 2024
Copy link
Collaborator

@vogelsgesang vogelsgesang left a comment

Choose a reason for hiding this comment

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

Thanks for this PR! Properly bundling and minifying the extensions has been on my TODO list for a long time already.

I know that there were discussions on "should we build this extension via Bazel", but afaik they stalled. As such, I would be happy to move on with this PR. We can later still switch to Bazel, in case somebody is willing to put in the effort for this switch

.vscodeignore Outdated Show resolved Hide resolved
package.json Outdated Show resolved Hide resolved
package.json Outdated Show resolved Hide resolved
package.json Show resolved Hide resolved
Copy link
Collaborator

@vogelsgesang vogelsgesang left a comment

Choose a reason for hiding this comment

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

Looks good to me. I am still waiting before merging this, to also give others a chance to review

scripts/package.sh Outdated Show resolved Hide resolved
@cwahbong
Copy link
Contributor Author

cwahbong commented Oct 20, 2024

Thanks for this PR! Properly bundling and minifying the extensions has been on my TODO list for a long time already.

I know that there were discussions on "should we build this extension via Bazel", but afaik they stalled. As such, I would be happy to move on with this PR. We can later still switch to Bazel, in case somebody is willing to put in the effort for this switch

I did a quick try (still not working) for using Bazel build for building this extension. It is more complicated even for only making a pbts command works in the build system. At first I thought it was at most just a bunch of genrules but it turns out it would be making npm repositories and I don't think I can finish them in a short time. (comparing to this pull request the first version is just done in under 10 minutes...)

Just saw #340 working on Bazel build, would move the discussion there.

@cwahbong
Copy link
Contributor Author

Icon paths need to be fixed.

The esbuild.js is copied from VSCode extension generator template
(github.com/microsoft/vscode-generator-code/tree/4812b7e/generators/app/templates/ext-command-ts/vscode-esbuild)
then format fixed by prettier.

This reduces the package size from ~5MB -> ~250KB.
@cwahbong cwahbong force-pushed the esbuild branch 2 times, most recently from d336fe7 to d685dbb Compare October 25, 2024 12:01
@cwahbong
Copy link
Contributor Author

I just made the corresponding changes in launch.json to support the debugging. I only validate that local breakpoint could be set in either "Launch Extension" and "Launch Extension Tests".

However I don't think I'm really understand how / why Debug Server works. It seems to be a debugging service for bazel build file instead of the plugin or typescript/javascript stuffs. I just made them into another binary, updating the referencedin package.json as well.

@@ -6,28 +6,29 @@
"type": "extensionHost",
"request": "launch",
"runtimeExecutable": "${execPath}",
"args": ["--extensionDevelopmentPath=${workspaceRoot}"],
"stopOnEntry": false,
Copy link
Contributor Author

Choose a reason for hiding this comment

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

stopOnEntry is reported invalid entry in my vscode, thus removing it.

@@ -6,28 +6,29 @@
"type": "extensionHost",
"request": "launch",
"runtimeExecutable": "${execPath}",
"args": ["--extensionDevelopmentPath=${workspaceRoot}"],
Copy link
Contributor Author

Choose a reason for hiding this comment

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

workspaceRoot is now deprecated

@@ -0,0 +1,10 @@
# Ignore all files by default.
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I found some examples and practices using .vscodeignore for white listing: so that we can invoke the vsce without changing the working directory or copying the included resources, and the layout for the resources should be the same no matter we minified or not.

@cwahbong
Copy link
Contributor Author

Still looking into the "watch" flow. I also have no idea for how to test these flow automatically to prevent regression.
For now I assume all developers are daily using it and would be triggered once broken again.

@@ -483,6 +488,7 @@
"eslint-plugin-jsdoc": "^48.2.2",
"js-yaml": "^4.1.0",
"mocha": "^10.4.0",
"npm-run-all": "^4.1.5",
"prettier": "^3.2.5",
Copy link
Contributor Author

@cwahbong cwahbong Oct 25, 2024

Choose a reason for hiding this comment

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

The usage of npm-run-all is referenced from https://github.com/microsoft/vscode-generator-code/blob/4812b7e/generators/app/templates/ext-command-ts/vscode-esbuild/package.json, but it has 1700+ dependent packages... I can revoke the modification for watch since I found it not really useful for vscode IDE...

Copy link
Contributor

Choose a reason for hiding this comment

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

That does seem like a lot of extra dependency weight (with the attendant impact on CI times and security alert noise) for something of marginal utility. Developers need to take explicit action to reload the extension anyway.

@cwahbong cwahbong requested a review from vogelsgesang October 25, 2024 13:14
@@ -483,6 +488,7 @@
"eslint-plugin-jsdoc": "^48.2.2",
"js-yaml": "^4.1.0",
"mocha": "^10.4.0",
"npm-run-all": "^4.1.5",
"prettier": "^3.2.5",
Copy link
Contributor

Choose a reason for hiding this comment

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

That does seem like a lot of extra dependency weight (with the attendant impact on CI times and security alert noise) for something of marginal utility. Developers need to take explicit action to reload the extension anyway.

js-yaml syntaxes/bazelrc.tmLanguage.yaml > syntaxes/bazelrc.tmLanguage.json

# Compile the rest of the project.
# Compile the rest of the project for development flow like testing.
tsc "$@" -p ./
Copy link
Contributor

Choose a reason for hiding this comment

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

Why do you still need tsc here? esbuild handles compilation. Running tsc remains useful for testing but not so much for build.

!dist/**/*.js
!icons/**/*.+(svg|license)
!media/**/*
!syntaxes/**/*.+(json|yaml|license)
Copy link
Contributor

Choose a reason for hiding this comment

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

yaml file shouldn't be included in the extension, only the form that's been compiled to json.

Suggested change
!syntaxes/**/*.+(json|yaml|license)
!syntaxes/**/*.+(json|license)

Do note that it was previously excluded.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants