rename to rules_js and remove toolchain boilerplate

jfirebaugh · Oct 29, 2021 · 14f8df0 · 14f8df0
1 parent 923d89d
commit 14f8df0
Show file tree

Hide file tree

Showing 12 changed files with 22 additions and 346 deletions.
diff --git a/BUILD.bazel b/BUILD.bazel
@@ -3,12 +3,12 @@ load(":version.bzl", "VERSION")
 
 # This declares the release artifact users
 pkg_tar(
-    name = "rules_mylang-" + VERSION,
+    name = "rules_js-" + VERSION,
     srcs = [
         "LICENSE",
         "README.md",
         "version.bzl",
-        "//mylang:package_content",
+        "//js:package_content",
     ],
     extension = "tar.gz",
     # It is all source code, so make it read-only.

diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
@@ -16,17 +16,17 @@ Otherwise later tooling on CI may yell at you about formatting/linting violation
 ## Using this as a development dependency of other rules
 
 You'll commonly find that you develop in another WORKSPACE, such as
-some other ruleset that depends on rules_mylang, or in a nested
+some other ruleset that depends on rules_js, or in a nested
 WORKSPACE in the integration_tests folder.
 
 To always tell Bazel to use this directory rather than some release
 artifact or a version fetched from the internet, run this from this
 directory:
 
 ```sh
-OVERRIDE="--override_repository=rules_mylang=$(pwd)/rules_mylang"
+OVERRIDE="--override_repository=rules_js=$(pwd)/rules_js"
 echo "build $OVERRIDE" >> ~/.bazelrc
 echo "query $OVERRIDE" >> ~/.bazelrc
 ```
 
-This means that any usage of `@rules_mylang` on your system will point to this folder.
+This means that any usage of `@rules_js` on your system will point to this folder.
diff --git a/README.md b/README.md
@@ -16,16 +16,12 @@ See https://docs.bazel.build/versions/main/skylark/deploying.html#readme
 
 Ready to get started? Copy this repo, then
 
-1. search for "com_myorg_rules_mylang" and replace with the name you'll use for your workspace
-1. search for "mylang" and replace with the language/tool your rules are for
-1. rename directory "mylang" similarly
-1. run `pre-commit install` to get lints (see CONTRIBUTING.md)
 1. if you don't need to fetch platform-dependent tools, then remove anything toolchain-related.
 1. delete this section of the README (everything up to the SNIP).
 
 ---- SNIP ----
 
-# Bazel rules for mylang
+# Bazel rules for js
 
 ## Installation
 
@@ -34,22 +30,22 @@ Include this in your WORKSPACE file:
 ```starlark
 load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
 http_archive(
-    name = "com_myorg_rules_mylang",
-    url = "https://github.com/myorg/rules_mylang/releases/download/0.0.0/rules_mylang-0.0.0.tar.gz",
+    name = "build_aspect_rules_js",
+    url = "https://github.com/myorg/rules_js/releases/download/0.0.0/rules_js-0.0.0.tar.gz",
     sha256 = "",
 )
 
-load("@com_myorg_rules_mylang//mylang:repositories.bzl", "mylang_rules_dependencies")
+load("@build_aspect_rules_js//js:repositories.bzl", "js_rules_dependencies")
 
-# This fetches the rules_mylang dependencies, which are:
+# This fetches the rules_js dependencies, which are:
 # - bazel_skylib
 # If you want to have a different version of some dependency,
 # you should fetch it *before* calling this.
 # Alternatively, you can skip calling this function, so long as you've
 # already fetched these dependencies.
-rules_mylang_dependencies()
+rules_js_dependencies()
 ```
 
 > note, in the above, replace the version and sha256 with the one indicated
-> in the release notes for rules_mylang
+> in the release notes for rules_js
 > In the future, our release automation should take care of this.
diff --git a/WORKSPACE b/WORKSPACE
@@ -3,21 +3,21 @@
 workspace(
     # If your ruleset is "official"
     # (i.e. is in the bazelbuild GitHub org)
-    # then this should just be named "rules_mylang"
+    # then this should just be named "rules_js"
     # see https://docs.bazel.build/versions/main/skylark/deploying.html#workspace
-    name = "com_myorg_rules_mylang",
+    name = "build_aspect_rules_js",
 )
 
 # Install our "runtime" dependencies which users install as well
-load("//mylang:repositories.bzl", "mylang_register_toolchains", "rules_mylang_dependencies")
+load("//js:repositories.bzl", "js_register_toolchains", "rules_js_dependencies")
 
-rules_mylang_dependencies()
+rules_js_dependencies()
 
-load(":internal_deps.bzl", "rules_mylang_internal_deps")
+load(":internal_deps.bzl", "rules_js_internal_deps")
 
-rules_mylang_internal_deps()
+rules_js_internal_deps()
 
-mylang_register_toolchains(
-    name = "mylang1_14",
-    mylang_version = "1.14.2",
+js_register_toolchains(
+    name = "js1_14",
+    js_version = "1.14.2",
 )
diff --git a/internal_deps.bzl b/internal_deps.bzl
@@ -7,7 +7,7 @@ statement from these, that's a bug in our distribution.
 load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
 load("@bazel_tools//tools/build_defs/repo:utils.bzl", "maybe")
 
-def rules_mylang_internal_deps():
+def rules_js_internal_deps():
     maybe(
         http_archive,
         name = "rules_pkg",

diff --git a/mylang/BUILD.bazel b/mylang/BUILD.bazel
diff --git a/mylang/defs.bzl b/mylang/defs.bzl
diff --git a/mylang/private/BUILD.bazel b/mylang/private/BUILD.bazel
diff --git a/mylang/private/toolchains_repo.bzl b/mylang/private/toolchains_repo.bzl
diff --git a/mylang/private/versions.bzl b/mylang/private/versions.bzl
diff --git a/mylang/repositories.bzl b/mylang/repositories.bzl