Closed petervdonovan closed 1 year ago
What would be a reasonable alternative to using a submodule? In any case, we need to build the language server. Providing a fix to vsce
sounds reasonable, but I'm afraid it might take a while for it to get merged?
Given that there are so many other things in progress that do not involve this issue, and that this issue does not affect the quality of the artifact, I would personally prefer to defer action on this.
We can depend on a fork of vsce
if it comes to that; I might prefer maintaining a fork over having to change the build and release workflows, since those aspects of our code base are the most time consuming to test.
Edit: To answer directly, I do not know what we would do without using a submodule. We did not originally use a submodule, but there is a reason why we switched.
Sounds reasonable! If the fix is quick (which it appears to be), then it might be worth submitting a PR for vsce
soon though. There is a chance that it will be adopted relatively soon, which would simplify things for us going forward.
Is this still a thing? I think the build is pretty fast now? Shall we close this?
I do not know but I saw that you updated vsce
today. I'm fine closing this since it is only a developer-facing issue. If it becomes a problem for me again in the future then I'll just fix it.
This algorithm is causing problems for us. The build has been super slow for a long time, and this slowness is totally unnecessary. Basically
vsce package
indexes directories that are ignored in.vscodeignore
-- in particular, thelingua-franca
submodule -- only to filter them out afterward. I was prompted to investigate this when I finally started getting anAllocation failed - JavaScript heap out of memory
error just by runningnpx vsce ls
.We need to either fix things on our end by not using the submodule, or else try to fix things on
vsce
's end.