Language-tools: Deploys are broken

Created on 7 Jun 2020  路  15Comments  路  Source: sveltejs/language-tools

My bad, still figuring it out, better to have an issue I can "close" when done

bug

Most helpful comment

Got it deploying properly again.

  • commented out the "rewire svelte-language-server to local version" part (we can remove that I think)
  • added missing parse5 dependency to svelte-language-server
  • re-added the prepublish build scripts
  • reverted the used monorepo-deploy version to one before using npm install --production. @orta I think it should be reverted to npm install, because else all the build steps will fail ("cannot found rollup/whatever"). But we should do npm prune --production afterwards to at least get rid of those modules afterwards EDIT: no we have to do that as a last step in prepublish ourselves, else it prunes too soon.

It's all still in a rough state which needs some cleanup, but the main problem is fixed.

I ended up not adding a bundle/minify step, so that's still to do, but separately.

All 15 comments

Deploys are working again for npm, but for the VSCode extension there is a bug I was not able to track down yet: The node_modules folder is missing in the build of the extension, so it will never start. You can revert to 99.0.33, that one should work.

how can we help? is it a problem with orta's action or with us?

I guess it's the actions. Since the deployment is tightly integrated with Orta's monorepo-deploy-repo, we cannot do much there right now I think.

Hrm, it should be running npm install before each deploy - but it doesn't sound like it

is it possible that the dependencies for svelte-vscode are wrong? This list seems very short:

  "devDependencies": {
        "@tsconfig/node12": "^1.0.0",
        "@types/node": "^13.9.0",
        "@types/vscode": "*",
        "typescript": "*"
    },
    "dependencies": {
        "svelte-language-server": "*",
        "vscode-languageclient": "^6.1.1"
    }

Scanned the packages, the following are imported packages: vscode, vscode-languageclient, vscode-languageserver-protocol (although only as type, so no use at runtime), svelte-language-server -> the dependency list seems ok?

Even if not - it would at least still have to create a node_modules folder with those packages in it. And second, if that was the problem, why did it not fail before?

It is definitely running npm install in the svelte-vscode` folder - so I'm interested in whether it's creating a subset of the dep tree somehow

Yeah it's really strange. Could it go missing during the deploy step with vsce? Or any weird behavior because the installation is done with npm and the (pre)publish with yarn?

Last deploy run now shows some npm errors about extraneous packages. All of those are from the devDependencies, I guess because they were installed but npm list --production only wants to see packages that are in dependencies.

If that is true, we would need to do two things:

  1. add @tsconfig/node12 under dependencies because it's used during build
  2. the monorepo-deploy-repo needs to use npm install --production

package.json has :

...
    "dependencies": {
        "svelte-language-server": "file:../language-server",   // <--- file:
...

Removing that rewire step from the build made the extension deploy again - thanks @mgholam for that find!
But it still does not contain the node_modules folder which is super strange because the log even says "hey that's a lot of js files".

Got it deploying properly again.

  • commented out the "rewire svelte-language-server to local version" part (we can remove that I think)
  • added missing parse5 dependency to svelte-language-server
  • re-added the prepublish build scripts
  • reverted the used monorepo-deploy version to one before using npm install --production. @orta I think it should be reverted to npm install, because else all the build steps will fail ("cannot found rollup/whatever"). But we should do npm prune --production afterwards to at least get rid of those modules afterwards EDIT: no we have to do that as a last step in prepublish ourselves, else it prunes too soon.

It's all still in a rough state which needs some cleanup, but the main problem is fixed.

I ended up not adding a bundle/minify step, so that's still to do, but separately.

馃憤 thanks @dummdidumm!

I shipped a commit first without the prune, and then another which drops the --production from the install to the monorepo deployer 馃憤

Working regularly again.

Was this page helpful?
0 / 5 - 0 ratings