Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

prepare for VSCode marketplace #1875

Merged
merged 1 commit into from
Jun 26, 2019
Merged

Conversation

garyverhaegen-da
Copy link
Contributor

This is the first step in a three-step process to get us to a point where the VSCode extension gets pushed to the marketplace automatically on every new release. Here are the steps:

  1. Get all the tooling necessary so that this commit (and hopefully future ones, assuming we don't break anything) is in a state that can be pushed to the marketplace. This includes:
  • Adding vsce to the dev-env.
  • Changes to the package.json file to reference the correct license & org.
  • Cosmetic changes to the README.
  1. Set up credentials on Azure Pipelines. This will be a bit tricky because those credentials expire, but sorting that out is not necessarily blocking for step 3. I'll initially seed the credentials from my own account while starting a conversation about how to manage them in the future.
  2. Add a job to the azure-cron pipeline, in the same style as the existing ones, which checks if we need to release a new version. As opposed to existing jobs (docs & Docker), this one cannot practically create releases for older versions, which is why it needs to be a separate PR: it will have to only consider versions that have been published after this one has been merged in (and therefore needs to know which commit sha this will end up having after squashing).

Huge thanks to @dasormeter for laying a lot of the groundwork this builds upon (see #416).

Copy link
Contributor

@neil-da neil-da left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me. Only question is if we can source vsce through Bazel rather than Nix, since we have a lot of node dependencies there anyway?

@garyverhaegen-da
Copy link
Contributor Author

Here is the diff switching from nix to Bazel, for easy comparison (excluding the generated files in nix/tools/vsce):

diff --git a/BUILD b/BUILD
index ed590eb5..de21c0ec 100644
--- a/BUILD
+++ b/BUILD
@@ -201,3 +201,12 @@ da_haskell_repl(
         "//daml-assistant/daml-helper",
     ],
 )
+
+# vsce executable for publishing to marketplace
+
+load("@build_bazel_rules_nodejs//:defs.bzl", "nodejs_binary")
+
+nodejs_binary(
+  name = "vsce",
+  entry_point = "//daml-foundations/daml-tools/daml-extension:node_modules/vsce/out/vsce",
+)
diff --git a/azure-cron.yml b/azure-cron.yml
index 6b8303c1..86eeaefd 100644
--- a/azure-cron.yml
+++ b/azure-cron.yml
@@ -177,8 +177,8 @@ jobs:
             echo "Publishing $GITHUB to VSCode Marketplace"
             git checkout $GITHUB
             cd daml-foundations/daml-tools/daml-extension
-            yarn
-            vsce publish ${GITHUB#v} -p $MARKETPLACE_TOKEN
+            bazel run @nodejs//:bin/yarn
+            bazel run @daml_extension_deps//vsce/bin:vsce -- publish ${GITHUB#v} -p $MARKETPLACE_TOKEN
           else
             if [[ "${GITHUB#v}" == "$MARKET" ]]; then
               echo "Version on marketplace is already the latest ($GITHUB)."
diff --git a/daml-foundations/daml-tools/daml-extension/package.json b/daml-foundations/daml-tools/daml-extension/package.json
index db208f8b..cebaa0e8 100644
--- a/daml-foundations/daml-tools/daml-extension/package.json
+++ b/daml-foundations/daml-tools/daml-extension/package.json
@@ -134,6 +134,7 @@
     "devDependencies": {
         "typescript": "3.3.3",
         "@types/node": "6.0.42",
-        "vscode": "1.1.33"
+        "vscode": "1.1.33",
+        "vsce": "1.64.0"
     }
 }
diff --git a/dev-env/bin/vsce b/dev-env/bin/vsce
deleted file mode 120000
index 943ba2d8..00000000
--- a/dev-env/bin/vsce
+++ /dev/null
@@ -1 +0,0 @@
-../lib/dade-exec-nix-tool
\ No newline at end of file
diff --git a/nix/packages.nix b/nix/packages.nix
index d3a2697d..ba25aff5 100644
--- a/nix/packages.nix
+++ b/nix/packages.nix
@@ -128,8 +128,6 @@ in rec {
       (import ./tools/live-server { inherit pkgs; nodejs = tools.node; }).live-server;
     license-checker =
       (import ./tools/license-checker { inherit pkgs; nodejs = tools.node; }).license-checker;
-    vsce =
-      (import ./tools/vsce { inherit pkgs; nodejs = tools.node; }).vsce;
 
     # This override is necessary to be able to run automated UI tests with Selenium 3.12.0
     # The override can be removed when nixpkgs snapshot moved past the commit of 6b91b0d09f582f308a8ad4de526df494ff363622
diff --git a/nix/tools/vsce/README.md b/nix/tools/vsce/README.md
deleted file mode 100644
index f402da9f..00000000
--- a/nix/tools/vsce/README.md
+++ /dev/null
@@ -1,3 +0,0 @@
-```
-node2nix --nodejs-8 -i node-packages.json
-```
diff --git a/nix/tools/vsce/node-packages.json b/nix/tools/vsce/node-packages.json
deleted file mode 100644
index f88b9601..00000000
--- a/nix/tools/vsce/node-packages.json
+++ /dev/null
@@ -1 +0,0 @@
-["vsce"]

Tradeoffs as I see them, after discussing with @aherrmann-da, @cocreature and @stefanobaghino-da:

  • +Bazel: ensures we use the same version of node, npm, yarn, etc. while deploying as while testing (e.g. right now dev-env yarn is 1.12.3 while Bazel yarn is 1.13.0)
  • +Bazel: may potentially work on Windows
  • +nix: command discoverable as it is in PATH through dev-env/bin
  • +nix: no forced correlation between our dependencies and vsce's own dependencies (all the way to the version of nodejs itself)
  • ~: Bazel requires adding vsce as a node devDependency of the extension, which makes it clear where the executable is needed but at the same time doesn't feel quite right
  • ~: discounting generated code, both approaches end up with the same number of lines

For what it's worth I've found the experience of setting it up through nix a lot more pleasant; finding the right values for the entry_point and the path in the bazel run commands was just painful, random trial and error, and while looking at the result now I can kind of see the logic, I still don't quite see how someone could look at the nodejs_binary entry and know what to type at the command line to run it.

All things considered I have a slight preference for the nix approach, mainly because I am very reluctant to tie our own dependencies with vsce's; I'd prefer thinking of it as an executable we download, and not need to care that it's currently written in JS and distributed through npm.

@garyverhaegen-da garyverhaegen-da merged commit 798e96c into master Jun 26, 2019
@garyverhaegen-da garyverhaegen-da deleted the prepare-for-marketplace branch June 26, 2019 12:56
@neil-da
Copy link
Contributor

neil-da commented Jun 26, 2019

Good to know on Bazel, thanks for tracking that down. Happy to stick with Nix given your preferences.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants