daml/compatibility/bazel_tools/create-daml-app/Main.hs

309 lines
12 KiB
Haskell
Raw Normal View History

-- Copyright (c) 2021 Digital Asset (Switzerland) GmbH and/or its affiliates. All rights reserved.
-- SPDX-License-Identifier: Apache-2.0
module Main (main) where
import qualified Bazel.Runfiles
import Control.Exception.Extra
import Control.Monad
import DA.Test.Process
import DA.Test.Tar
import DA.Test.Util
Include puppeteer tests in compat tests (#6018) * Include puppeteer tests in compat tests This PR adds the puppeteer based tests to the compatibility tests. This also means that they are now actually compatibility tests. Before, we only tested the SDK side. Apart from process management being a nightmare on Windows as usually, there are two things that might stick out here: 1. I’ve replaced the `sh_binary` wrapper by a `cc_binary`. There is a lengthy comment explaining why. I think at the moment, we could actually get rid of the wraper completely and add JAVA to path in the tests that need it but at least for now, I’d like to keep it until we are sure that we don’t need to add more to it (and then it’s also in the git history if we do need to resurrect it). 2. These tests are duplicated now similar to the `daml ledger *` tests. The reasoning here is different. They depend on the SDK tarball either way so performance wise there is no reason to keep them. However, we reference the other file in the docs which means we cannot change it freely. What we could do is to make this sufficiently flexible to handle both the `daml start` case and separate `daml sandbox`/`daml json-api` processes and then we can reference it in the docs. There is still added complexity for Windows but that’s necessary for users as well that want to run this on Windows so that seems unavoidable. (I should probably also remove my snarky comments :innocent:) I’d like to kee it duplicated for this PR and then we can clean it up afterwards. changelog_begin changelog_end * Bump timeouts changelog_begin changelog_end
2020-05-22 15:02:59 +03:00
import qualified Data.Aeson.Extra as Aeson
import Data.Conduit ((.|), runConduitRes)
import qualified Data.ByteString as BS
import qualified Data.ByteString.Lazy as BSL
import qualified Data.Conduit.Combinators as Conduit
import qualified Data.Conduit.Tar as Tar
import qualified Data.Conduit.Zlib as Zlib
import qualified Data.HashMap.Strict as HMS
import Data.Maybe
import Data.Proxy
import Data.Tagged
import qualified Data.Text as T
import System.Directory.Extra
import System.Environment.Blank
import System.FilePath
import System.Info.Extra
import System.IO.Extra
import System.Process
import Test.Tasty
import Test.Tasty.HUnit
import Test.Tasty.Options
data Tools = Tools
{ damlBinary :: FilePath
, damlLedgerPath :: FilePath
, damlTypesPath :: FilePath
, damlReactPath :: FilePath
, messagingPatch :: FilePath
, npmPath :: FilePath
, nodePath :: FilePath
, patchPath :: FilePath
Include puppeteer tests in compat tests (#6018) * Include puppeteer tests in compat tests This PR adds the puppeteer based tests to the compatibility tests. This also means that they are now actually compatibility tests. Before, we only tested the SDK side. Apart from process management being a nightmare on Windows as usually, there are two things that might stick out here: 1. I’ve replaced the `sh_binary` wrapper by a `cc_binary`. There is a lengthy comment explaining why. I think at the moment, we could actually get rid of the wraper completely and add JAVA to path in the tests that need it but at least for now, I’d like to keep it until we are sure that we don’t need to add more to it (and then it’s also in the git history if we do need to resurrect it). 2. These tests are duplicated now similar to the `daml ledger *` tests. The reasoning here is different. They depend on the SDK tarball either way so performance wise there is no reason to keep them. However, we reference the other file in the docs which means we cannot change it freely. What we could do is to make this sufficiently flexible to handle both the `daml start` case and separate `daml sandbox`/`daml json-api` processes and then we can reference it in the docs. There is still added complexity for Windows but that’s necessary for users as well that want to run this on Windows so that seems unavoidable. (I should probably also remove my snarky comments :innocent:) I’d like to kee it duplicated for this PR and then we can clean it up afterwards. changelog_begin changelog_end * Bump timeouts changelog_begin changelog_end
2020-05-22 15:02:59 +03:00
, testDepsPath :: FilePath
, testTsPath :: FilePath
, codegenPath :: FilePath
}
newtype DamlOption = DamlOption FilePath
instance IsOption DamlOption where
Update Bazel 2.1.0 --> 3.3.1 (#6761) * Upgrade nixpkgs revision * Remove unused minio It used to be used as a gateway to push the Nix cache to GCS, but has since been replaced by nix-store-gcs-proxy. * Update Bazel on Windows changelog_begin changelog_end * Fix hlint warnings The nixpkgs update implied an hlint update which enabled new warnings. * Fix "Error applying patch" Since Bazel 2.2.0 the order of generating `WORKSPACE` and `BUILD` files and applying patches has been reversed. The allows users to define patches to these files that will not be immediately overwritten. However, it also means that patches on another repository's original `WORKSPACE` file will likely become invalid. * https://github.com/bazelbuild/bazel/commit/a948eb7255b8418f0bba1c819a58972066577d6f * https://github.com/bazelbuild/bazel/issues/10681 Hint: If you're generating a patch with `git` then you can use the following command to exclude the `WORKSPACE` file. ``` git diff ':(exclude)WORKSPACE' ``` * Update rules_nixpkgs * nixpkgs location expansion escaping * Drop --noincompatible_windows_native_test_wrapper * client_server_test using sh_inline_test client_server_test used to produce an executable shell script in form of a text file output. However, since the removal of `--noincompatible_windows_native_test_wrapper` this no longer works on Windows since `.sh` files are not directly executable on Windows. This change fixes the issue by producing the script file in a dedicated rule and then wrapping it in a `sh_test` rule which also works on Windows. * daml_test using sh_inline_test * daml_doc_test using sh_inline_test * _daml_validate_test using sh_inline_test * damlc_compile_test using sh_inline_test * client_server_test find .exe on Windows * Bump Windows cache for Bazel update Remove `clean --expunge` after merge. Co-authored-by: Andreas Herrmann <andreas.herrmann@tweag.io>
2020-07-23 10:46:04 +03:00
defaultValue = DamlOption "daml"
parseValue = Just . DamlOption
optionName = Tagged "daml"
optionHelp = Tagged "runfiles path to the daml executable"
newtype DamlLedgerOption = DamlLedgerOption FilePath
instance IsOption DamlLedgerOption where
defaultValue = DamlLedgerOption []
parseValue = Just . DamlLedgerOption
optionName = Tagged "daml-ledger"
optionHelp = Tagged "path to extracted daml-ledger package"
newtype DamlTypesOption = DamlTypesOption FilePath
instance IsOption DamlTypesOption where
defaultValue = DamlTypesOption []
parseValue = Just . DamlTypesOption
optionName = Tagged "daml-types"
optionHelp = Tagged "path to extracted daml-types package"
newtype DamlReactOption = DamlReactOption FilePath
instance IsOption DamlReactOption where
defaultValue = DamlReactOption []
parseValue = Just . DamlReactOption
optionName = Tagged "daml-react"
optionHelp = Tagged "path to extracted daml-react package"
newtype MessagingPatchOption = MessagingPatchOption FilePath
instance IsOption MessagingPatchOption where
defaultValue = MessagingPatchOption ""
parseValue = Just . MessagingPatchOption
optionName = Tagged "messaging-patch"
optionHelp = Tagged "path to messaging patch"
newtype NpmOption = NpmOption FilePath
instance IsOption NpmOption where
defaultValue = NpmOption ""
parseValue = Just . NpmOption
optionName = Tagged "npm"
optionHelp = Tagged "path to npm"
newtype NodeOption = NodeOption FilePath
instance IsOption NodeOption where
defaultValue = NodeOption ""
parseValue = Just . NodeOption
optionName = Tagged "node"
optionHelp = Tagged "path to node"
newtype PatchOption = PatchOption FilePath
instance IsOption PatchOption where
defaultValue = PatchOption ""
parseValue = Just . PatchOption
optionName = Tagged "patch"
optionHelp = Tagged "path to patch"
Include puppeteer tests in compat tests (#6018) * Include puppeteer tests in compat tests This PR adds the puppeteer based tests to the compatibility tests. This also means that they are now actually compatibility tests. Before, we only tested the SDK side. Apart from process management being a nightmare on Windows as usually, there are two things that might stick out here: 1. I’ve replaced the `sh_binary` wrapper by a `cc_binary`. There is a lengthy comment explaining why. I think at the moment, we could actually get rid of the wraper completely and add JAVA to path in the tests that need it but at least for now, I’d like to keep it until we are sure that we don’t need to add more to it (and then it’s also in the git history if we do need to resurrect it). 2. These tests are duplicated now similar to the `daml ledger *` tests. The reasoning here is different. They depend on the SDK tarball either way so performance wise there is no reason to keep them. However, we reference the other file in the docs which means we cannot change it freely. What we could do is to make this sufficiently flexible to handle both the `daml start` case and separate `daml sandbox`/`daml json-api` processes and then we can reference it in the docs. There is still added complexity for Windows but that’s necessary for users as well that want to run this on Windows so that seems unavoidable. (I should probably also remove my snarky comments :innocent:) I’d like to kee it duplicated for this PR and then we can clean it up afterwards. changelog_begin changelog_end * Bump timeouts changelog_begin changelog_end
2020-05-22 15:02:59 +03:00
newtype TestDepsOption = TestDepsOption FilePath
instance IsOption TestDepsOption where
defaultValue = TestDepsOption ""
parseValue = Just . TestDepsOption
optionName = Tagged "test-deps"
optionHelp = Tagged "path to testDeps.json"
newtype TestTsOption = TestTsOption FilePath
instance IsOption TestTsOption where
defaultValue = TestTsOption ""
parseValue = Just . TestTsOption
optionName = Tagged "test-ts"
optionHelp = Tagged "path to index.test.ts"
newtype CodegenOption = CodegenOption FilePath
instance IsOption CodegenOption where
defaultValue = CodegenOption ""
parseValue = Just . CodegenOption
optionName = Tagged "codegen"
optionHelp = Tagged "path to codegen output"
withTools :: (IO Tools -> TestTree) -> TestTree
withTools tests = do
askOption $ \(DamlOption damlPath) -> do
askOption $ \(DamlLedgerOption damlLedgerPath) -> do
askOption $ \(DamlTypesOption damlTypesPath) -> do
askOption $ \(DamlReactOption damlReactPath) -> do
askOption $ \(MessagingPatchOption messagingPatch) -> do
askOption $ \(NpmOption npmPath) -> do
askOption $ \(NodeOption nodePath) -> do
askOption $ \(PatchOption patchPath) -> do
Include puppeteer tests in compat tests (#6018) * Include puppeteer tests in compat tests This PR adds the puppeteer based tests to the compatibility tests. This also means that they are now actually compatibility tests. Before, we only tested the SDK side. Apart from process management being a nightmare on Windows as usually, there are two things that might stick out here: 1. I’ve replaced the `sh_binary` wrapper by a `cc_binary`. There is a lengthy comment explaining why. I think at the moment, we could actually get rid of the wraper completely and add JAVA to path in the tests that need it but at least for now, I’d like to keep it until we are sure that we don’t need to add more to it (and then it’s also in the git history if we do need to resurrect it). 2. These tests are duplicated now similar to the `daml ledger *` tests. The reasoning here is different. They depend on the SDK tarball either way so performance wise there is no reason to keep them. However, we reference the other file in the docs which means we cannot change it freely. What we could do is to make this sufficiently flexible to handle both the `daml start` case and separate `daml sandbox`/`daml json-api` processes and then we can reference it in the docs. There is still added complexity for Windows but that’s necessary for users as well that want to run this on Windows so that seems unavoidable. (I should probably also remove my snarky comments :innocent:) I’d like to kee it duplicated for this PR and then we can clean it up afterwards. changelog_begin changelog_end * Bump timeouts changelog_begin changelog_end
2020-05-22 15:02:59 +03:00
askOption $ \(TestDepsOption testDepsPath) -> do
askOption $ \(TestTsOption testTsPath) -> do
askOption $ \(CodegenOption codegenPath) -> do
let createRunfiles :: IO (FilePath -> FilePath)
createRunfiles = do
runfiles <- Bazel.Runfiles.create
mainWorkspace <- fromMaybe "compatibility" <$> getEnv "TEST_WORKSPACE"
pure (\path -> Bazel.Runfiles.rlocation runfiles $ mainWorkspace </> path)
withResource createRunfiles (\_ -> pure ()) $ \locateRunfiles -> do
let tools = do
damlBinary <- locateRunfiles <*> pure damlPath
pure Tools
{ damlBinary
, damlLedgerPath
, damlTypesPath
, damlReactPath
, messagingPatch
, npmPath
, nodePath
, patchPath
Include puppeteer tests in compat tests (#6018) * Include puppeteer tests in compat tests This PR adds the puppeteer based tests to the compatibility tests. This also means that they are now actually compatibility tests. Before, we only tested the SDK side. Apart from process management being a nightmare on Windows as usually, there are two things that might stick out here: 1. I’ve replaced the `sh_binary` wrapper by a `cc_binary`. There is a lengthy comment explaining why. I think at the moment, we could actually get rid of the wraper completely and add JAVA to path in the tests that need it but at least for now, I’d like to keep it until we are sure that we don’t need to add more to it (and then it’s also in the git history if we do need to resurrect it). 2. These tests are duplicated now similar to the `daml ledger *` tests. The reasoning here is different. They depend on the SDK tarball either way so performance wise there is no reason to keep them. However, we reference the other file in the docs which means we cannot change it freely. What we could do is to make this sufficiently flexible to handle both the `daml start` case and separate `daml sandbox`/`daml json-api` processes and then we can reference it in the docs. There is still added complexity for Windows but that’s necessary for users as well that want to run this on Windows so that seems unavoidable. (I should probably also remove my snarky comments :innocent:) I’d like to kee it duplicated for this PR and then we can clean it up afterwards. changelog_begin changelog_end * Bump timeouts changelog_begin changelog_end
2020-05-22 15:02:59 +03:00
, testDepsPath
, testTsPath
, codegenPath
}
tests tools
main :: IO ()
main = withTempDir $ \npmCache -> do
setEnv "npm_config_cache" npmCache True
setEnv "TASTY_NUM_THREADS" "1" True
let options =
[ Option @DamlOption Proxy
, Option @DamlLedgerOption Proxy
, Option @DamlTypesOption Proxy
, Option @DamlReactOption Proxy
, Option @MessagingPatchOption Proxy
, Option @NpmOption Proxy
, Option @NodeOption Proxy
, Option @PatchOption Proxy
Include puppeteer tests in compat tests (#6018) * Include puppeteer tests in compat tests This PR adds the puppeteer based tests to the compatibility tests. This also means that they are now actually compatibility tests. Before, we only tested the SDK side. Apart from process management being a nightmare on Windows as usually, there are two things that might stick out here: 1. I’ve replaced the `sh_binary` wrapper by a `cc_binary`. There is a lengthy comment explaining why. I think at the moment, we could actually get rid of the wraper completely and add JAVA to path in the tests that need it but at least for now, I’d like to keep it until we are sure that we don’t need to add more to it (and then it’s also in the git history if we do need to resurrect it). 2. These tests are duplicated now similar to the `daml ledger *` tests. The reasoning here is different. They depend on the SDK tarball either way so performance wise there is no reason to keep them. However, we reference the other file in the docs which means we cannot change it freely. What we could do is to make this sufficiently flexible to handle both the `daml start` case and separate `daml sandbox`/`daml json-api` processes and then we can reference it in the docs. There is still added complexity for Windows but that’s necessary for users as well that want to run this on Windows so that seems unavoidable. (I should probably also remove my snarky comments :innocent:) I’d like to kee it duplicated for this PR and then we can clean it up afterwards. changelog_begin changelog_end * Bump timeouts changelog_begin changelog_end
2020-05-22 15:02:59 +03:00
, Option @TestDepsOption Proxy
, Option @TestTsOption Proxy
, Option @CodegenOption Proxy
]
let ingredients = defaultIngredients ++ [includingOptions options]
defaultMainWithIngredients ingredients $
withTools $ \getTools -> do
testGroup "Create DAML App tests"
[ test getTools
]
where
test getTools = testCaseSteps "Getting Started Guide" $ \step -> withTempDir $ \tmpDir' -> do
-- npm gets confused when the temporary directory is not under 'private' on mac.
let tmpDir
| isMac = "/private" <> tmpDir'
| otherwise = tmpDir'
Tools{..} <- getTools
Include puppeteer tests in compat tests (#6018) * Include puppeteer tests in compat tests This PR adds the puppeteer based tests to the compatibility tests. This also means that they are now actually compatibility tests. Before, we only tested the SDK side. Apart from process management being a nightmare on Windows as usually, there are two things that might stick out here: 1. I’ve replaced the `sh_binary` wrapper by a `cc_binary`. There is a lengthy comment explaining why. I think at the moment, we could actually get rid of the wraper completely and add JAVA to path in the tests that need it but at least for now, I’d like to keep it until we are sure that we don’t need to add more to it (and then it’s also in the git history if we do need to resurrect it). 2. These tests are duplicated now similar to the `daml ledger *` tests. The reasoning here is different. They depend on the SDK tarball either way so performance wise there is no reason to keep them. However, we reference the other file in the docs which means we cannot change it freely. What we could do is to make this sufficiently flexible to handle both the `daml start` case and separate `daml sandbox`/`daml json-api` processes and then we can reference it in the docs. There is still added complexity for Windows but that’s necessary for users as well that want to run this on Windows so that seems unavoidable. (I should probably also remove my snarky comments :innocent:) I’d like to kee it duplicated for this PR and then we can clean it up afterwards. changelog_begin changelog_end * Bump timeouts changelog_begin changelog_end
2020-05-22 15:02:59 +03:00
setEnv "CI" "yes" True
step "Create app from template"
withCurrentDirectory tmpDir $ do
callProcess damlBinary ["new", "create-daml-app", "create-daml-app"]
let cdaDir = tmpDir </> "create-daml-app"
let uiDir = cdaDir </> "ui"
step "Patch the application code with messaging feature"
withCurrentDirectory cdaDir $ do
callProcessSilent patchPath ["-p2", "-i", messagingPatch]
forM_ ["MessageEdit", "MessageList"] $ \messageComponent ->
assertFileExists ("ui" </> "src" </> "components" </> messageComponent <.> "tsx")
step "Extract codegen output"
extractTarGz codegenPath $ uiDir </> "daml.js"
-- we patch all the 'package.json' files to point to the local versions of the TypeScript
-- libraries.
genFiles <- listFilesRecursive $ uiDir </> "daml.js"
forM_ [file | file <- genFiles, takeFileName file == "package.json"] (patchTsDependencies uiDir)
withCurrentDirectory uiDir $ do
step "Set up libraries and workspaces"
setupNpmEnv uiDir [(DamlTypes, damlTypesPath)
, (DamlLedger, damlLedgerPath)
, (DamlReact, damlReactPath)
]
Include puppeteer tests in compat tests (#6018) * Include puppeteer tests in compat tests This PR adds the puppeteer based tests to the compatibility tests. This also means that they are now actually compatibility tests. Before, we only tested the SDK side. Apart from process management being a nightmare on Windows as usually, there are two things that might stick out here: 1. I’ve replaced the `sh_binary` wrapper by a `cc_binary`. There is a lengthy comment explaining why. I think at the moment, we could actually get rid of the wraper completely and add JAVA to path in the tests that need it but at least for now, I’d like to keep it until we are sure that we don’t need to add more to it (and then it’s also in the git history if we do need to resurrect it). 2. These tests are duplicated now similar to the `daml ledger *` tests. The reasoning here is different. They depend on the SDK tarball either way so performance wise there is no reason to keep them. However, we reference the other file in the docs which means we cannot change it freely. What we could do is to make this sufficiently flexible to handle both the `daml start` case and separate `daml sandbox`/`daml json-api` processes and then we can reference it in the docs. There is still added complexity for Windows but that’s necessary for users as well that want to run this on Windows so that seems unavoidable. (I should probably also remove my snarky comments :innocent:) I’d like to kee it duplicated for this PR and then we can clean it up afterwards. changelog_begin changelog_end * Bump timeouts changelog_begin changelog_end
2020-05-22 15:02:59 +03:00
step "Install Jest, Puppeteer and other dependencies"
addTestDependencies "package.json" testDepsPath
patchTsDependencies uiDir "package.json"
-- use '--scripts-prepend-node-path' to make sure we are using the correct 'node' binary
retry 3 (callProcessSilent npmPath ["install", "--scripts-prepend-node-path"])
Include puppeteer tests in compat tests (#6018) * Include puppeteer tests in compat tests This PR adds the puppeteer based tests to the compatibility tests. This also means that they are now actually compatibility tests. Before, we only tested the SDK side. Apart from process management being a nightmare on Windows as usually, there are two things that might stick out here: 1. I’ve replaced the `sh_binary` wrapper by a `cc_binary`. There is a lengthy comment explaining why. I think at the moment, we could actually get rid of the wraper completely and add JAVA to path in the tests that need it but at least for now, I’d like to keep it until we are sure that we don’t need to add more to it (and then it’s also in the git history if we do need to resurrect it). 2. These tests are duplicated now similar to the `daml ledger *` tests. The reasoning here is different. They depend on the SDK tarball either way so performance wise there is no reason to keep them. However, we reference the other file in the docs which means we cannot change it freely. What we could do is to make this sufficiently flexible to handle both the `daml start` case and separate `daml sandbox`/`daml json-api` processes and then we can reference it in the docs. There is still added complexity for Windows but that’s necessary for users as well that want to run this on Windows so that seems unavoidable. (I should probably also remove my snarky comments :innocent:) I’d like to kee it duplicated for this PR and then we can clean it up afterwards. changelog_begin changelog_end * Bump timeouts changelog_begin changelog_end
2020-05-22 15:02:59 +03:00
step "Run Puppeteer end-to-end tests"
copyFile testTsPath (uiDir </> "src" </> "index.test.ts")
-- we need 'npm-cli.js' in the path for the following test
mbOldPath <- getEnv "PATH"
setEnv "PATH" (takeDirectory npmPath <> (searchPathSeparator : fromMaybe "" mbOldPath)) True
callProcess npmPath ["run", "test", "--ci", "--all", "--scripts-prepend-node-path"]
Include puppeteer tests in compat tests (#6018) * Include puppeteer tests in compat tests This PR adds the puppeteer based tests to the compatibility tests. This also means that they are now actually compatibility tests. Before, we only tested the SDK side. Apart from process management being a nightmare on Windows as usually, there are two things that might stick out here: 1. I’ve replaced the `sh_binary` wrapper by a `cc_binary`. There is a lengthy comment explaining why. I think at the moment, we could actually get rid of the wraper completely and add JAVA to path in the tests that need it but at least for now, I’d like to keep it until we are sure that we don’t need to add more to it (and then it’s also in the git history if we do need to resurrect it). 2. These tests are duplicated now similar to the `daml ledger *` tests. The reasoning here is different. They depend on the SDK tarball either way so performance wise there is no reason to keep them. However, we reference the other file in the docs which means we cannot change it freely. What we could do is to make this sufficiently flexible to handle both the `daml start` case and separate `daml sandbox`/`daml json-api` processes and then we can reference it in the docs. There is still added complexity for Windows but that’s necessary for users as well that want to run this on Windows so that seems unavoidable. (I should probably also remove my snarky comments :innocent:) I’d like to kee it duplicated for this PR and then we can clean it up afterwards. changelog_begin changelog_end * Bump timeouts changelog_begin changelog_end
2020-05-22 15:02:59 +03:00
addTestDependencies :: FilePath -> FilePath -> IO ()
addTestDependencies packageJsonFile extraDepsFile = do
packageJson <- readJsonFile packageJsonFile
extraDeps <- readJsonFile extraDepsFile
let newPackageJson = Aeson.lodashMerge packageJson extraDeps
BSL.writeFile packageJsonFile (Aeson.encode newPackageJson)
readJsonFile :: FilePath -> IO Aeson.Value
readJsonFile path = do
-- Read file strictly to avoid lock being held when we subsequently write to it.
content <- BSL.fromStrict <$> BS.readFile path
case Aeson.decode content of
Nothing -> error ("Could not decode JSON object from " <> path)
Just val -> return val
extractTarGz :: FilePath -> FilePath -> IO ()
extractTarGz targz outDir = do
runConduitRes
$ Conduit.sourceFile targz
.| Zlib.ungzip
.| Tar.untar (restoreFile (\a b -> fail (T.unpack $ a <> b)) outDir)
setupNpmEnv :: FilePath -> [(TsLibrary, FilePath)] -> IO ()
setupNpmEnv uiDir libs = do
forM_ libs $ \(tsLib, path) -> do
let name = tsLibraryName tsLib
let uiLibPath = uiDir </> name
extractTarGz path uiLibPath
patchTsDependencies uiDir $ uiLibPath </> "package.json"
-- | Overwrite dependencies to our TypeScript libraries to point to local file dependencies in the
-- 'ui' directory in the specified package.json file.
patchTsDependencies :: FilePath -> FilePath -> IO ()
patchTsDependencies uiDir packageJsonFile = do
packageJson0 <- readJsonFile packageJsonFile
case packageJson0 of
Aeson.Object packageJson ->
case HMS.lookup "dependencies" packageJson of
Just (Aeson.Object dependencies) -> do
let depNames = HMS.keys dependencies
-- patch dependencies to point to local files if they are present in the package.json
let patchedDeps =
HMS.fromList
([ ( "@daml.js/create-daml-app"
, Aeson.String $
T.pack $
"file:" <> "./daml.js/create-daml-app-0.1.0")
| "@daml.js/create-daml-app" `elem` depNames
] ++
[ (depName, Aeson.String $ T.pack $ "file:" <> libRelPath)
| tsLib <- allTsLibraries
, let libName = tsLibraryName tsLib
, let libPath = uiDir </> libName
, let libRelPath =
makeRelative (takeDirectory packageJsonFile) libPath
, let depName = T.replace "-" "/" $ T.pack $ "@" <> libName
, depName `elem` depNames
]) `HMS.union`
dependencies
let newPackageJson =
Aeson.Object $
HMS.insert "dependencies" (Aeson.Object patchedDeps) packageJson
-- Make sure we have write permissions before writing
p <- getPermissions packageJsonFile
setPermissions packageJsonFile (setOwnerWritable True p)
BSL.writeFile packageJsonFile (Aeson.encode newPackageJson)
Nothing -> pure () -- Nothing to patch
_otherwise -> error $ "malformed package.json:" <> show packageJson
_otherwise -> error $ "malformed package.json:" <> show packageJson0
Include puppeteer tests in compat tests (#6018) * Include puppeteer tests in compat tests This PR adds the puppeteer based tests to the compatibility tests. This also means that they are now actually compatibility tests. Before, we only tested the SDK side. Apart from process management being a nightmare on Windows as usually, there are two things that might stick out here: 1. I’ve replaced the `sh_binary` wrapper by a `cc_binary`. There is a lengthy comment explaining why. I think at the moment, we could actually get rid of the wraper completely and add JAVA to path in the tests that need it but at least for now, I’d like to keep it until we are sure that we don’t need to add more to it (and then it’s also in the git history if we do need to resurrect it). 2. These tests are duplicated now similar to the `daml ledger *` tests. The reasoning here is different. They depend on the SDK tarball either way so performance wise there is no reason to keep them. However, we reference the other file in the docs which means we cannot change it freely. What we could do is to make this sufficiently flexible to handle both the `daml start` case and separate `daml sandbox`/`daml json-api` processes and then we can reference it in the docs. There is still added complexity for Windows but that’s necessary for users as well that want to run this on Windows so that seems unavoidable. (I should probably also remove my snarky comments :innocent:) I’d like to kee it duplicated for this PR and then we can clean it up afterwards. changelog_begin changelog_end * Bump timeouts changelog_begin changelog_end
2020-05-22 15:02:59 +03:00
data TsLibrary
= DamlLedger
| DamlReact
| DamlTypes
deriving (Bounded, Enum)
allTsLibraries :: [TsLibrary]
allTsLibraries = [minBound .. maxBound]
tsLibraryName :: TsLibrary -> String
tsLibraryName = \case
DamlLedger -> "daml-ledger"
DamlReact -> "daml-react"
DamlTypes -> "daml-types"