search

runem / lit-analyzer

Monorepository for tools that analyze lit-html templates
MIT License
319 stars 38 forks source link

bump dependencies & simplify enabled rules logic #98

Closed 43081j closed 4 years ago

43081j commented 4 years ago

do it only in one place and bump some deps.

seems to work fine, let me know if anything looks off.

typescript can't be updated until WCA has the same version bump.

edit: no clue why ci fails, exact same stuff passes locally with a clean repo (git clean -xdf)

43081j commented 4 years ago

closing because 1.2.0 shuffles a whole load of this logic around

runem commented 4 years ago

I was actually just writing a comment in here which I will post/add nevertheless:

The reason the CI fails is because of problems with vsce and mono-repositories. Unfortunately, vsce doesn't yet support mono-repositories with linked dependencies. You can read more about the issue here: https://github.com/Microsoft/vscode-vsce/issues/203. In order to get around this problem and debug locally developed dependencies (ts-lit-plugin and lit-analyzer) in the vscode extension project, I had to make a small script that copies locally built lib files to packages/vscode-lit-plugin/node_modules/{ts-lit-plugin, lit-analyzer} (see copylink script). The problem we experience in this PR occurs because lit-analyzer has updated dependencies, but the dependencies in packages/vscode-lit-plugin are installed using dependencies of the published version of lit-analyzer (thus installing 'old' dependencies). vsce checks for out-of-sync dependencies when packaging and crashes. I found a way around this on the 1.2.0 branch, and I can cherry-pick the fix if necessary.

runem commented 4 years ago

In general if we change code around rule logic I would love it to be based on the 1.2.0 branch, so we avoid too many merge conflicts :+1: But if you think this (or another PR) is very important for an upcoming release of 1.1.x I'm also fine with handling the merge conflicts :-)

43081j commented 4 years ago

its ok thats a shame about the vscode issue though.

ill probably throw together a different branch on top of the 1.2 branch, if anything. i think your new rule sets achieve what i was going for mostly. the dependency updates are nice to have though so i might still do that, as the newer ava has debugging built in (like node's --inspect).