search

runem / lit-analyzer

Monorepository for tools that analyze lit-html templates
MIT License
318 stars 36 forks source link

Test the packaged version of the extension on CI and get it working #233

Closed rictic closed 2 years ago

rictic commented 2 years ago

With this, the .vsix file works for me. Turns out the issue was that vscode-web-custom-data couldn't be resolved when loading the extension. Opening the TS server log has been super helpful for debugging.

We don't yet have an integration test of loading the .vsix file, but I think I'm fairly close to something kinda close that should work. The trick is to package up the vsix file, rename it to a zip file, unzip the extension folder from within it, and then move that to a directory entirely outside of the repo filesystem entirely (so that recursive node_module resolution doesn't pick up deps that might be in the repo but not in the package), then point the extensionDevelopmentPath at that directory.

justinfagnani commented 2 years ago

nice sleuthing!

wrt unzipping out of the repo tree... you should also be able to put it in a subfolder. Node resolution looks up for any ancestor containing a node_modules folder, but not to any cousin. So repo/temp/node_modules won't be looked at.

rictic commented 2 years ago

Ah, I tried putting it in the root dir of the repo, and the problem is that vscode-web-custom-data is present in the root node_modules directory! Not sure what's doing that, maybe some clever lerna optimization?

rictic commented 2 years ago

Ha ha! Moving it outside the repo entirely (I know, it's gross, and a violation of the implicit boundary) successfully reproduced the error that we've been seeing where the .visx file doesn't work! https://github.com/runem/lit-analyzer/runs/5074481601?check_suite_focus=true

And then adding the vscode-web-custom-data dep back in gets the same test passing! https://github.com/runem/lit-analyzer/runs/5074504695?check_suite_focus=true

justinfagnani commented 2 years ago

Ah, I tried putting it in the root dir of the repo, and the problem is that vscode-web-custom-data is present in the root node_modules directory! Not sure what's doing that, maybe some clever lerna optimization?

No, there's a custom copy step that I would like to get rid of

rictic commented 2 years ago

I think it might be lerna bootstrap --hoist

rictic commented 2 years ago

but in any case, putting it outside the repo itself is a more hermetic option anyways

justinfagnani commented 2 years ago

oh, oh... there is a copy step for the first-party extension. I thought that's what you were talking about. Yeah, hoist would do this here. It'd be good to turn hoisting off for the extension, and if that's not possible, maybe just do it for the whole repo. I had added more packages to nohoist, but it seems like it might be a game of whack-a-mole.