What about building debug package on CI?
It's not very difficult. But I'd like to first discuss how to introduce the job.
| Step | Release | Debug | PR |
| ------------------ | ------- | ----- | --- |
| Checkout | Do | Do | Do |
| Set debug manifest | - | Do | - |
| Build ^ | Do | Do | Do |
| Test | Do | - | Do |
| Upload VSIX | Do | Do | - |
^: Build commands are a little bit different.
As shown above, these three jobs have steps in common, so it's possible to merge some by strategy.
I prefer to put Release and Debug together, and create a separate workflow for PR.
What's your opinion?
What about building debug package on CI?
Brilliant!
Not sure whether we should call it "release" build, probably "latest"/"preview"/"dev"?
whether we should call it "release" build
My "release" and "debug" referred to build mode. 馃槄
That is:
webpack --mode productiontsc -p ./馃憣
I have a new idea about building debug package:
Run webpack in development mode.
-"vscode:prepublish": "webpack --mode production",
+"vscode:prepublish": "webpack --mode development",
In this way:
package.json.(Note: As mentioned somewhere, I finally decided to use word "production" instead of "release".)
I haven't tried webpack --mode development before. If in this mode we can see the function name from the CPU profile, I think it is good.
see the function name from the CPU profile
Yes.
In development mode, webpack preserves all module names, function names, and comments.
Although wrappers introduced by webpack also appear in call tree, I guess it's not a big problem.
It has been 2.5 months since our last update. I am going to do this and publish a new version in this weekend.
v3.4.0 馃殌
So, the debug branch is no longer needed. We can delete it safely.
Most helpful comment
It has been 2.5 months since our last update. I am going to do this and publish a new version in this weekend.