As I was adding support to a sample app for the third time, I decided I
might as well clean it up a bit and add support for everyone.
This is completely optional, activated by (build-time) environment
variables, and should be trivial to remove for users who don't care
about it. In an ideal world we'd have options to `daml new` and this
would be one, but I think adding it out-of-the-box is a better
alternative than letting people figure this out on their own.
CHANGELOG_BEGIN
- The `create-daml-app` template now includes support for a third
authentication scheme (in addition to the existing "dev mode" and Daml
Hub support): Auth0.
CHANGELOG_END
The current README dates back to when `create-daml-app` was its own
repo, and seems mostly written from the perspective of being the default
home page for the project. These days, `create-daml-app` serves two
purposes:
1. As the core starting point for the Getting Started Guide, we can
assume people who are totally new to Daml will be following the
getting started guide. How else would they even know about this
template? In that case, I think it's fair to assume the user will *not*
be looking to the README for guidance. Therefore, repeating the
documentation here seems a bit pointless.
2. As a template to quickstart the creation of a "custom" app that is
not the GSG. For that use-case, the README is the place where people
would look for information, but at that point the information they're
looking for are more along the lines of quick refreshers of what
commands to run than explanations on how to use the app as Alice and
Bob.
CHANGELOG_BEGIN
CHANGELOG_END
It currently has all it needs for the docs to build, but not quite for
people to use it as a useful result of the triggers docs page: without
the UI components, it's hard to see anything the triggers are supposed
to do.
CHANGELOG_BEGIN
CHANGELOG_END
* rewrite trigger docs to follow gsg
Per #10419 point 4, I've rewritten the Triggers section to build upon
the Getting Started Guide instead of inventing its own example.
Compared to #10395, this has a lot more explanations as this page must
now serve the dual purpose of being a possible "next step" from the GSG
and being the main reference page for triggers. It's also lost the "next
steps" section, which I think is a bit of a shame, but it doesn't really
make sense here.
There's also no easy way for people not interested in the GSG to follow
along; should we expose the "completed GSG" as a tempate?
CHANGELOG_BEGIN
CHANGELOG_END
* keep copy-trigger as a template
* fix copy-trigger project name
* make up gsg-trigger template
* remove awkward sentence, fix existing typo
* update code to use when{,Some}
* add to
* swap emitCommands and getCommandsInFlight
* typo
* insist on state-correction perspective
* fix copy-trigger tests
* add back copy-trigger to whitelist
* add gsg-trigger to whitelist
When opening #10342 I was only aware of the `.gitignore`; @cocreature's
comment made me find out the `.dlint.yaml`, and then, testing it, I
realized we ended up with the ignore rule twice. It does not seem to be
causing any issue in cursory tests, but still, I think it's worth
cleaning up.
CHANGELOG_BEGIN
CHANGELOG_END
This ends up transitively bumping yargs-parser which has a
vulnerability but more generally I also just like being on the latest version.
changelog_begin
changelog_end
* update Daml Hub auth in create-daml-app
Current documentation says the token is passed as a cookie. This is a
little bit more secure than passing it as a URL param, as it used to be.
Note that while it is no longer documented behaviour, the token is
actually still passed as a param (in addition to the cookie), so
existing users are not broken (yet). Still, better if the code we
generate for them matches our current docs.
CHANGELOG_BEGIN
CHANGELOG_END
* review comment
Setting this manually has resulted in #9397 where we use a scala
version that doesn’t have a silencer version. This PR changes the
quickstart template to use the scala version we also use in our builds
which should avoid them getting out of sync in the future.
changelog_begin
changelog_end
* Apply new logo to create-daml-app template
changelog_begin
[SDK Assistant] New Daml logo on create-daml-app template
changelog_end
* Fix logo alignment, change capitalization of page title
Older versions emit security warnings. I went through the getting
started guide and CI should also test this so reasonable confident it
doesn’t break things™.
changelog_begin
changelog_end
* Replace many occurrences of DAML with Daml
* Update docs logo
* A few more CLI occurrences
CHANGELOG_BEGIN
- Change DAML capitalization and docs logo
CHANGELOG_END
* Fix some over-eager replacements
* A few mor occurrences in md files
* Address comments in *.proto files
* Change case in comments and strings in .ts files
* Revert changes to frozen proto files
* Also revert LF 1.11
* Update get-daml.sh
* Update windows installer
* Include .py files
* Include comments in .daml files
* More instances in the assistant CLI
* some more help texts
This commit fixes a few copyright headers that have been missed in the
automatic update on Jan 1, as well as the generation code in the compat
workspace so it generates the right headers.
CHANGELOG_BEGIN
CHANGELOG_END
As we strive for more inclusiveness, we are becoming less comfortable
with historically-charged terms being used in our everyday work.
This is targeted for merge on Dec 26, _after_ the necessary
corresponding changes at both the GitHub and Azure Pipelines levels.
CHANGELOG_BEGIN
- DAML Connect development is now conducted from the `main` branch,
rather than the `master` one. If you had any dependency on the
digital-asset/daml repository, you will need to update this parameter.
CHANGELOG_END
This follows up on #7066 and exposes the new underlying multi-key and
multi-query stream functions through the React bindings. Following the
same reasoning as in #7066, we therefore deprecate the existing
functions (with no intention of removing them) as they become redundant.
CHANGELOG_BEGIN
* JavaScript Client Libraries: Updated React bindings to expose the
recent addition of multi-key and multi-query streams in @daml/ledger.
The singular versions are marked as deprecated as they have become
redundant.
The upgrade path for `useStreamQuery` is very straightforward: the
query factory remains optional, but if specified it should return an
array of queries instead of a single query. The array may be empty,
which will return all contracts for that template (similar as not
passing in a query factory). The return values of `useStreamQuery` and
`useStreamQueries` are the same type.
```
useStreamQuery(T) --> useStreamQueries(T)
useStreamQuery(T, () => query, ...) --> useStreamQueries(T, () => [query], ...)
```
The upgrade path for `useStreamFetchByKey` is only slightly more
involved as the return type of `useStreamFetchByKeys` is a new type
called `FetchByKeysResult` instead of the existing `FetchResult`.
`FetchByKeysResult` differs from `FetchResult` in that it contains a
`contracts` field with an array of contracts instead of a singular
`contract` field. (It differs from `QueryResult` in that each element of
the returned array can also be `null`, if there is no corresponding
active contract.) Call sites can be updated as follows:
```
const {loading, contract} = useStreamFetchByKey(T, () => k, ...);
-->
const {loading, contracts} = useStreamFetchByKeys(T, () => [k], ...));
const contract = contracts[0];
```
CHANGELOG_END
This executes the code generations specified in the daml.yaml
configuration file on every invocation of `daml start`
and hence frees the user of doing it manually.
CHANGELOG_BEGIN
- [DAML Assistant] The `daml start` now runs all the code generators
specified in the `daml.yaml` project configuration file under the
`codegen` stanza. This frees the user of doing so manually on every
change to the DAML model.
CHANGELOG_END
We deprecate specifying the template when calling `daml new` via a
positional argument, as in
```sh
daml new foo skeleton
```
The new syntax is
```sh
daml new foo --template skeleton
```
Whenever the former version is used, we now print a not that it is
deprecated and that the latter version is the recommended way.
CHANGELOG_BEGIN
[DAML Assistant]
- Deprecate specifying the template for `daml new` via a positional
argument.
CHANGELOG_END
When an error happend during decoding of JSON API answers due to missing
templates, the error was just displayed as an empty object '{}'.
CHANGELOG_BEGIN
CHANGELOG_END
* Migrate skeleton to DAML Script
Also kills the separate setup module since it’s the same thing
changelog_begin
changelog_end
* Fix test
changelog_begin
changelog_end
* Factor out tar/gzip reproducibility flags
* use mktgz in package-app
* Bazel managed tar/gzip
* Remove quiet = True
As stated in the comment this is no longer required with Bazel >= 3.0.
* Build package-app as a sh_binary
This way Bazel will manage the runtime dependencies tar, gzip, mktgz,
and patchelf.
package-app.sh changes directory so it needs to make sure that all paths
are absolute and that the runfiles tree/manifest location is forwarded
to programs called by package-app.sh.
* Avoid file path too long errors
* Fix readlink -f on MacOS
* Document abspath
changelog_begin
changelog_end
Co-authored-by: Andreas Herrmann <andreas.herrmann@tweag.io>
If a user were to follow @cocreature's [suggestions][0] for compiler
warnings, the current skeleton template would generate two warnings.
That seems like it may give a bad impression, so I believe we should fix
it, even though the warnings are not enabled by default.
[0]: https://discuss.daml.com/t/making-the-most-out-of-daml-compiler-warnings/739
CHANGELOG_BEGIN
CHANGELOG_END
* Respect project name in create-daml-app
Now `daml new foobar create-daml-app` creates a project called
`foobar` replacing the name everywhere. The tests now run twice once
with the original project name since that’s what we use in the GSG and
once with a modified one. I guess you could argue that only running
the second should be enough so I’m open to removing the first one.
fixes#6681
changelog_begin
- [DAML Assistant] `daml new foobar create-daml-app` now properly
respects the project name and creates a project called `foobar`
instead of hardcoding the name fo `create-daml-app`.
changelog_end
* .
changelog_begin
changelog_end
* Remove debugging output
changelog_begin
changelog_end
The intention was to pull in the source for the GSG but it turns out
that the templates tarball doesn’t just bundle up files, it also
includes generated scala code for the scala quickstart which depends
on damlc. This PR splits the GSG sources including the patching into a
separate rule which does not depend on damlc and only copies that in
live-preview.
changelog_begin
changelog_end
Buildifier now comes with a handy attachment to catch single `\`
characters inside strings and replace them with `\\` if the escape
sequence is invalid. Skylark/Python will do this at runtime anyway; this
just makes it clearer what the actual behavior is.
I needed to change `\` characters at the end of lines to `\\` manually
in order to stop Buildifier from simply concatenating the lines
together. Everything else was automatic.
CHANGELOG_BEGIN
CHANGELOG_END
* Remove the copyright header from the skelton
It doesn't make sense to annoy our users with our copyright for on a
template. And the over abundance of empty lines has annoyed me so many
times.
* Add NO_AUTO_COPYRIGHT file
CHANGELOG_BEGIN
CHANGELOG_END
The issue is described in a comment (since I want to preserve it) but
here’s the brief summary:
Calling `follow` twice can result in contention if we do not wait in
between. That is shown in the log of the JSON API. For some reason
that ends up propagating to a misleading Target closed error from
puppeteer.
This PR addresses the problem by waiting for the list of followers to
be updated which definitely implies that the ledger has seen the
command.
changelog_begin
changelog_end
I don’t know if this fixes the “Target closed” issues since I never
managed to reproduce them but I’d rather debug them on the latest
version :)
changelog_begin
changelog_end
`waitForSelector` returns immediately if the selector is already
present (which is documented). This means that the waitForSelector
after the second follow isn’t doing anything since we already waited
for after the first follow. `waitForFunction` seemed like the simplest
solution and doesn’t require patching the HTML which is a bit finnicky
in the compat tests.
changelog_begin
changelog_end
CHANGELOG_BEGIN
[create-daml-app] Change the create-daml-app template so that it can run against a HTTP JSON API port specified in the environment variable REACT_APP_LEDGER_ID
CHANGELOG_END
* Upgrade puppeteer
We’ve seen a couple of issues in the compatibility tests of the form
```
Error: Protocol error (Runtime.callFunctionOn): Target closed.
```
Looking at the issue tracker in puppeteer this might be fixed in newer
versions and I don’t see why we should stick to a fairly old version
anyway.
changelog_begin
changelog_end
* Upgrade nodejs
changelog_begin
changelog_end
* temporary add a step to kill node_modules
changelog_begin
changelog_end
* Kill live server and try to fix Windows
changelog_begin
changelog_end
* Undo rm
changelog_begin
changelog_end
This adds an empty template for the daml assistant. This is very helpful
for writing katacoda's, because otherwise you have to delete contained
source files in the `skeleton` project everytime as a first step. The
README in the `daml` directory is mainly there to get the daml directory
in the template.
CHANGELOG_BEGIN
CHANGELOG_END
The `da` tool has not existed for a while now and it's unlikely any new
user will need to know about the upgrade path. I think starting from
1.2.0 it makes sense not to have that documenation around anymore.
Note that we do have references to the upgrade page in the release
notes, so leaving them as is would break building the documentation. My
preference would have been to turn those references into "external"
links to the relevant version, but unfortunately, these are versions
(`0.12.15` and `0.12.18`) that, for various reasons, we cannot build
anymore and do not have in pre-built form. I have therefore decided to
change the links in the release notes to link to the latest existing
version of that page (which is pretty much what it already did), i.e.
specifically link to `1.1.1`.
CHANGELOG_BEGIN
CHANGELOG_END
* 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 😇) 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
Previously we changed to running the sandbox and JSON API separately to
have more control over port allocation. Now the same behaviour is
possible using `daml start`, which is preferable because it's what we
suggest users of the Getting Started Guide should use. This change
returns to using `daml start` in the end-to-end test. We use the default ports
for the sandbox and JSON API as we do in the guide.
changelog_begin
changelog_end
changelog_begin
changelog_end
* Be a bit more generous with the login/logout test timeout
* Use fsPromises.stat and remove port files before starting to be safe
This PR gets yarn test running the Puppeteer end-to-end tests in the GSG integration test.
The first step of the test is adding the extra dependencies (Jest, Puppeteer and more). The GSG recommends a yarn add command, but this does not work against HEAD. This is because yarn add does not use resolutions in the parent package.json, and then complains about unknown versions 0.0.0 of the daml TS libaries. The solution here is to hack in the extra dependencies into the ui/package.json and then yarn install. This works, but it hard codes version numbers which we would need to maintain. I would like to be able to say version "latest", which is what yarn add would install.
The next step of the test is to copy the index.test.ts file and run yarn test in CI mode.
I've moved the GSG test to a new create-daml-app-tests target. It's marked "exclusive" in Bazel until we figure out how to avoid hardcoding port numbers. This is a bit tricky since the HTTP port is hardcoded in a couple of places in ui/package.json.
Finally, this PR gets the GSG testing docs to reference the code in the new templates/create-daml-app-test-resources folder.
changelog_begin
changelog_end
* Diff with messaging feature and some noise manually removed
* Bazel target to use patch file in other build targets
* Patch file as data dep for integration tests
* Attempt to patch and test messaging feature in create-daml-app test
changelog_begin
changelog_end
* Use exports_files instead of filegroup
* Remove file existence checks that don't make sense
* Add patch to dev_env and reference it from integration tests
* Include patch on windows for later
* Set up yarn env again after codegen
* Restore file check
* Fix typo in comment on util function
* Add Tasty steps to make process explicit
* Use messaging patch for code snippets in GSG
* Use messaging code from template instead of copy
* Remove copied message code
* Refactor script to copy template code with messaging patch
* No need to retry second yarn install (only local deps should be updated)
* Used `daml codegen java` instead of calling the codegen from maven
This should hopefully fix the issues with mismatched versions of
slf4j.
changelog_begin
changelog_end
* Move config to daml.yaml
* Remove alternative invocation via maven from docs
We avoided infix syntax here for `elem` but still used it for
`notElem` which doesn’t make much sense. Also we lost the config to
disable the lint when integrating the example in this repo. This
resulted in our own code producing a lint which is obviously a bad
idea.
side note: I think this lint does make sense once you
are familiar with the syntax and I feel slightly bad about disabling
more and more lints so for now I’m keeping it in the config.
changelog_begin
changelog_end