Merge pull request #2 from khajavi/publish-docs-to-npm-registry

Publish Docs to The NPM Registry

.github/workflows/site.yml

@@ -0,0 +1,28 @@
+# This file was autogenerated using `zio-sbt` via `sbt generateGithubWorkflow` 
+# task and should be included in the git repository. Please do not edit 
+# it manually. 
+
+name: website
+
+on:
+  release:
+    types: [ published ]
+
+jobs:
+  publish-docs:
+    runs-on: ubuntu-20.04
+    timeout-minutes: 30
+    steps:
+      - uses: actions/checkout@v3.1.0
+        with:
+          fetch-depth: 0
+      - name: Setup Scala and Java
+        uses: olafurpg/setup-scala@v13
+      - uses: actions/setup-node@v3
+        with:
+          node-version: '16.x'
+          registry-url: 'https://registry.npmjs.org'
+      - name: Publishing Docs to NPM Registry
+        run: sbt publishToNpm
+        env:
+          NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}

.gitignore

@@ -7,3 +7,4 @@ project/metals.sbt
 .DS_Store
 .DS_Store/
 target/
+.idea

README.md

@@ -4,11 +4,9 @@
 | --- | --- | --- | 
 | [![Release Artifacts][Badge-SonatypeReleases]][Link-SonatypeReleases] |[![Badge-Scaladex-page]][Link-Scaladex-page] |[![Badge-Twitter]][Link-Twitter] |
 
-
-
 Allows you to build programs as mere descriptions with maximum polymorphism, maximum modularity, zero abstraction leakage, and zero casting.
 
-It is **a Scala take on the following paper in Haskell, on parametrising the program with logical constraints at every node, without compromising modularity**
+It is **a Scala take on the following paper in Haskell, on parametrizing the program with logical constraints at every node, without compromising modularity**
 
 http://www.doc.ic.ac.uk/~wlj05/files/Deconstraining.pdf
 
@@ -17,81 +15,6 @@ An excerpt from the paper:
 
 _"The key principle that underpins our idea is that implementation- specific constraints should be imposed at the point of use of a data type, not at the point of definition, i.e. it embodies the established principle that an interface should be separated from its implementation(s)."_
 
-
-## Quick Start
-
-Example: https://github.com/afsalthaj/constraintless/blob/master/src/main/scala/thaj/constraintless/examples/Expr.scala
-
-
- ```scala
-
-libraryDependencies ++= Seq("io.github.afsalthaj" %% "constraintless" % "0.1.4")
-
-```
-
-## Context
-
-The key to many inspectable programs such as an execution planner, a configuration DSL etc is the basic concept of "programs as descriptions", but this idea comes with limitations.
-
-This description (or data) can easily turn out to be a Generalised ADT that can be recursive, such that compiler has to traverse through the unknown types (existential) and for the compiler to do any advanced/useful stuff with it, it needs to know more about these types.
-
-The obvious implication of having to handle "unknown" is that, the data should hold on to informations as constraints (that are relevant to implementation) on types at the definition site. A possible solution is to compromise on parametric polymorphism, or fall back to relying unsafe/safe (relative) casting (asInstanceOf).
-
-This naive approach imposes modularity issues, and possible runtime crashes. The reasonsing and solution is given in the above paper, and this project solves the exact problem in scala.
-
-
-## Why not the Hughes schema?
-
-It doesn't allow you to have a compiler with multiple constraints.
-
-
-A few excerpts from the paper on why it doesn't work:
-
-```scala
-class Typeable p a valueP :: a → p a
-```
-
-```scala
-newtype SM a = SM {fromSM :: Int}
-
-instance IntBool a ⇒ Typeable SM a where
-  valueP = SM · toInt
-```
-
-```scala
-
-newtype Pretty a = Pretty {fromPretty :: String}
-
-instance Show a ⇒ Typeable Pretty a where valueP = Pretty · show
-
-```
-
-```scala
-data Exp p a where
-ValueE::Typeable p a ⇒ a → Exp p a
-
-CondE ::Expp Bool→Exp p a → Exp p a → Exp p a 
-
-EqE :: Eq a ⇒ Exp p a → Exp p a → Exp p Bool
-```
-
-
-```scala
-pretty :: Exp Pretty a → String // works
-compileSM :: Exp SM a → String // works
-
-
-```
-
- However, now suppose that we wish to apply the two functions to the same expression, as in:
-
-```scala
-f :: Exp p a → . . .
-f e = ...(compileSM e)...(pretty e)..
-```
-
-and that's impossible
-
 [Badge-Scaladex-page]: https://index.scala-lang.org/afsalthaj/constraintless/latest.svg "Scaladex"
 [Badge-SonatypeReleases]: https://img.shields.io/nexus/r/https/oss.sonatype.org/io.github.afsalthaj/constraintless_2.12.svg "Sonatype Releases"
 [Badge-Twitter]: https://img.shields.io/twitter/follow/zioscala.svg?style=plastic&label=follow&logo=twitter

build.sbt

@@ -22,3 +22,14 @@ libraryDependencies ++= (
       )
     )
 )
+
+lazy val docs = project
+  .in(file("zio-constraintless-docs"))
+  .settings(
+    publish / skip := true,
+    moduleName     := "zio-constraintless-docs",
+    scalacOptions -= "-Yno-imports",
+    scalacOptions -= "-Xfatal-warnings"
+  )
+  .dependsOn(core)
+  .enablePlugins(WebsitePlugin)

docs/index.md

@@ -0,0 +1,90 @@
+---
+id: index
+title: "Introduction to ZIO Constraintless"
+sidebar_label: "ZIO Constraintless"
+---
+
+Allows you to build programs as mere descriptions with maximum polymorphism, maximum modularity, zero abstraction leakage, and zero casting.
+
+It is **a Scala take on the following paper in Haskell, on parametrising the program with logical constraints at every node, without compromising modularity**
+
+http://www.doc.ic.ac.uk/~wlj05/files/Deconstraining.pdf
+
+An excerpt from the paper:
+
+
+_"The key principle that underpins our idea is that implementation- specific constraints should be imposed at the point of use of a data type, not at the point of definition, i.e. it embodies the established principle that an interface should be separated from its implementation(s)."_
+
+
+## Quick Start
+
+Example: https://github.com/afsalthaj/constraintless/blob/master/src/main/scala/thaj/constraintless/examples/Expr.scala
+
+
+```sbt
+libraryDependencies += "io.github.afsalthaj" %% "constraintless" % "@VERSION@"
+```
+
+## Context
+
+The key to many inspectable programs such as an execution planner, a configuration DSL etc is the basic concept of "programs as descriptions", but this idea comes with limitations.
+
+This description (or data) can easily turn out to be a Generalised ADT that can be recursive, such that compiler has to traverse through the unknown types (existential) and for the compiler to do any advanced/useful stuff with it, it needs to know more about these types.
+
+The obvious implication of having to handle "unknown" is that, the data should hold on to informations as constraints (that are relevant to implementation) on types at the definition site. A possible solution is to compromise on parametric polymorphism, or fall back to relying unsafe/safe (relative) casting (asInstanceOf).
+
+This naive approach imposes modularity issues, and possible runtime crashes. The reasonsing and solution is given in the above paper, and this project solves the exact problem in scala.
+
+
+## Why not the Hughes schema?
+
+It doesn't allow you to have a compiler with multiple constraints.
+
+
+A few excerpts from the paper on why it doesn't work:
+
+```scala
+class Typeable p a valueP :: a → p a
+```
+
+```scala
+newtype SM a = SM {fromSM :: Int}
+
+instance IntBool a ⇒ Typeable SM a where
+  valueP = SM · toInt
+```
+
+```scala
+
+newtype Pretty a = Pretty {fromPretty :: String}
+
+instance Show a ⇒ Typeable Pretty a where valueP = Pretty · show
+
+```
+
+```scala
+data Exp p a where
+ValueE::Typeable p a ⇒ a → Exp p a
+
+CondE ::Expp Bool→Exp p a → Exp p a → Exp p a 
+
+EqE :: Eq a ⇒ Exp p a → Exp p a → Exp p Bool
+```
+
+
+```scala
+pretty :: Exp Pretty a → String // works
+compileSM :: Exp SM a → String // works
+
+
+```
+
+However, now suppose that we wish to apply the two functions to the same expression, as in:
+
+```scala
+f :: Exp p a → . . .
+f e = ...(compileSM e)...(pretty e)..
+```
+
+and that's impossible
+

docs/package.json

@@ -0,0 +1,5 @@
+{
+  "name": "@zio.dev/zio-constraintless",
+  "description": "ZIO Constraintless Documentation",
+  "license": "Apache-2.0"
+}

docs/sidebars.js

@@ -0,0 +1,7 @@
+const sidebars = {
+  sidebar: [
+    "index"
+  ]
+};
+
+module.exports = sidebars;

project/plugins.sbt

@@ -1 +1,4 @@
 addSbtPlugin("com.github.sbt" % "sbt-ci-release" % "1.5.10")
+addSbtPlugin("dev.zio" % "zio-sbt-website" % "0.0.0+84-6fd7d64e-SNAPSHOT")
+
+resolvers += Resolver.sonatypeRepo("public")