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
* Fixes#7451 by telling users to use `$HOME/.daml/bin` instead of `~/.daml/bin` when setting up the PATH variable.
In addition, this PR streamlines the instructions a bit by not telling users to restart their computers (they only need to restart the terminal) and by verifying the variables only after setting them both up, so they only need to restart the terminal once (without jumping around the instructions).
changelog_begin
changelog_end
* reinstate some restarts
* Emphasize that it is the Terminal app from macOS
NPM doesn’t actually need this (at least it didn’t for me locally and
hopefully CI agrees) to pick up changes and it emits a very
scary-looking warning if you do pass it.
changelog_begin
changelog_end
- Put Windows first, and add a direct link to the installer.
- Move the manual step to a separate page.
- Link to AdoptOpenJDK as they have by far the simplest download page.
CHANGELOG_BEGIN
CHANGELOG_END
We’ve had a few confused users run into issues because of
this. `fsevents` (which is basically impossible to avoid as a
dependency) requires NodeJS 8.16 but for some reason Ubuntu 18.04
sticks to the unsupported 8.10.
changelog_begin
changelog_end
* Extend `daml new` to accept template as an option
The two positional arguments keep confusing users so this PR changes
things to allow the template to be passed via `--template`. Using a
positional argument still works so this is not breaking.
I’ve updated all docs to use the less confusing syntax.
changelog_begin
- [DAML Assistant] You can now use ``daml new project-name
--template=template-name`` instead of ``daml new project-name
template-name``. The old CLI syntax continues to be supported.
changelog_end
* Update docs/source/getting-started/index.rst
Co-authored-by: Martin Huschenbett <martin.huschenbett@posteo.me>
Co-authored-by: Martin Huschenbett <martin.huschenbett@posteo.me>
Added a new section in the cheat-sheet for basic DAML concepts (there's anotehr PR for it). This PR links the cheat-sheet to the GSG. This was a requirement that came out of the user tests where testers said that they would like to have a quick overview of the most important DAML concepts explained (they found jumping through the glossary and the rest of the docs too complicated).
CHANGELOG_BEGIN
CHANGELOG_END
Noobs had a problem running yarn install v1.12.3
[1/4] Resolving packages...
success Already up-to-date.
Done in 0.40s. second time around when they^ve changed the code. Simply put they would way too often (almost alqways) forget to include when calling yarn install v1.12.3
[1/4] Resolving packages...
success Already up-to-date.
Done in 0.34s.. This would be a very simple workaround that woould lead to them being aware from the very first step that there's the parameter that needs to be called.
CHANGELOG_BEGIN
CHANGELOG_END
* PATH instruction settings
We've been getting the same feedback now for two users tests that users have somewhat hard time figuring out how to set the variable. Also tonce they download the SDK the somehow miss ghe message/instructions that they need to add to variable
CHANGELOG_BEGIN
CHANGELOG_END
* Added own instructions for setting the variables
* Added the necessary headers
* Fixed the title underline too short
* Update docs/source/getting-started/path-variables.rst
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
* Update docs/source/getting-started/path-variables.rst
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
* Update docs/source/getting-started/path-variables.rst
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
* Update docs/source/getting-started/installation.rst
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
* Addressing Moritz's and Samir's feedback
* Single and double quotes fix
* Update docs/source/getting-started/installation.rst
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
* Update docs/source/getting-started/path-variables.rst
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
* Restarting the computer wording fix
* Bash/shell wording fix
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
In user tets users complained that they were missing an overview of how all the components in the GSG are connected. This is a very simple fix addressing it: the 'App Architecture' and 'Your First Feature' sections are moved to be on the same level as 'Build Your App'
CHANGELOG_BEGIN
CHANGELOG_END
After going through the GSG users were not sure what are the next steps. Adding the next steps at the end of the GSG is an easy fix for this,
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
pgp.keyserver.io seems to have lost our key
somehow. pool.sks-keyservers.net is the pool that includes the MIT gpg
keyserver and others so hopefully it is somewhat reliable.
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)
Yarn does not pick up changes to file: dependencies and link:
dependencies are unusable because Windows so we add an explicit
install step that refreshes them. It doesn’t make any sense to do
dependency resolution again here and could break something for
unrelated reasons so I added --frozen-lockfile as well.
changelog_begin
changelog_end
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
The call to `yarn build` in the Getting Started guide is completely
useless for everything that follows (it would only be necessary if you
want to deploy the app) and quite time consuming. Let's just remove it!
CHANGELOG_BEGIN
CHANGELOG_END
Packages com.digitalasset.daml and com.daml have been unified under com.daml
Ledger API and DAML-LF DEV protos have also been moved from `com/digitalasset`
to `com/daml` on the file system.
Protos for already released DAML LF versions (1.6, 1.7, 1.8) stay in the
package `com.digitalasset`.
CHANGELOG_BEGIN
[SDK] All Java and Scala packages starting with
``com.digitalasset.daml`` and ``com.digitalasset`` are now consolidated
under ``com.daml``. Simply changing imports should be enough to
migrate your code.
CHANGELOG_END
* Move quickstart to java bindings section
* Change title of quickstart to Getting Started with ...
* Move GSG to Getting Started (and rename in index)
* Rewrite a bunch of references to quickstart
* Update reference and give more specific name
changelog_begin
- [Docs] Replace IOU quickstart with full stack Getting Started Guide
changelog_end
* Replace daml-ledger link
* Use getting started guide in redirects
I've completely removed the possibility to call `daml codegen ts`. I'm
happy to add in back in a followup PR once I've seen that all our tests
pass without it existing.
CHANGELOG_BEGIN
CHANGELOG_END
Our plan for `daml2js` is to populate the `name` and `version` field
of the generated `package.json` files with the name and version of
the input DALF. Once this is done, you would expect to refer to the
package generated from `create-daml-app-0.1.0.dar` via
```typescript
import ... from '@daml.js/create-daml-app';`
```
Since we currently depend on the package by file paths anyway, we can
already pretend to have the right behavior in place.
In this style you can also depend on two different versions of the same
DAML package. This will happen during upgrades, a situation we're
already facing in DAVL. There it can be solved via the following two
lines in the `dependencies` field of the `package.json`:
```
...
"davl-v4": "file:../daml.js/davl-0.0.4",
"davl-v5": "file:../daml.js/davl-0.0.5",
...
```
CHANGELOG_BEGIN
CHANGELOG_END
As expected, the `puppeteer` library used to demonstrate how to test
DAML apps end-to-end, causes issues in CI. It is not very unlikely
that users of the getting started guide would run into the same issues.
In addition, `puppeteer` is a _huge_ dependency, we should probably not
shove down everybody's throat who just wants to walk throught the GSG.
Thus, this PR moves everything related to testing out of
`create-daml-app` and exclusively into the docs. This is completly
lacking tests, but since it wasn't tested before either, I consider
this acceptable. My manual tests succeeded.
Since merging this might unblock quite a few other PRs, I defer test
into a followup PR.
CHANGELOG_BEGIN
CHANGELOG_END
* Copy templates into docs build directory to reference in code snippets
changelog_begin
changelog_end
* Remove ui-before code copies
* Rename daml folder to daml-after and remove tags for before code
* Fix a link and wording
Change the output directory given to `daml codegen ts` from `daml-ts`
to `daml.js`. This is naming is in line with the fact that `daml2ts`
puts all generated packages into the `@daml.js` scope. A renaming of
`daml2ts` into `daml2js` is immiment.
This PR also changes a few small documentation issues the
search-and-replace has surfaced.
CHANGELOG_BEGIN
CHANGELOG_END
* Initial commit with create-daml-app master
* Include create-daml-app in build rule
* Make daml.yaml a template in version and project name
* Remove git attributes
* Remove license and azure config
* Remove scripts
* Don't overwrite config files in build rule
* Template version numbers in package.json, to be replaced by the assistant
* Rename to package.json.template
changelog_begin
changelog_end
* Add copyright headers
* Do template substitutions in all .template files
And don't special case daml new create-daml-app (so it treats it as a
regular template).
* Add create-daml-app to integration tests
* Remove WIP warning
* Move towards setup that works on head
* Make local copies of the TS libs in the templates tarball
* Hardcode project name for now
* Use isExtensionOf
* Remove service worker
* remove robots.txt (don't even know what it is)
* Revert "Make local copies of the TS libs in the templates tarball"
This reverts commit 1289581fb4a82af3ab534baf978a2c6ed895d538.
* Retemplatize TS lib versions. For head builds these will be installed using npm
* Remove daml/ledger from resolutions for daml-ts
* Comment about test secret
* Remove special create-daml-app assistant command and test that won't work anymore
* Remove redundant imports and export
* Remove old create-daml-app tests
* Remove yarn.lock
* Clean up integration test (just daml new and build atm)
* Add daml/ledger as a resolution for daml-ts
* Remove top level package.json
* Update daml.js version
* Use new import scheme for generated TS
* Update readme with new codegen and build steps
* Use start-navigator in daml.yaml
* Increase a couple of timeouts in tests (either sandbox or TS lib is a bit slower?)
* Update GSG intro with new build steps
* Remove daml2ts -p flag and --start-navigator flag from GSG instructions
* Don't use start-navigator flag in ui tests
* Temporary readme describing how to manually test the create-daml-app template
* Update code samples in app arch section of GSG
* Update code samples in testing doc
* Remove copied create-daml-app code
* Indent docs markers to be more subtle
* Update visible code in Messages (after) section
This needs to be kept up to date properly somehow.
* Update text to useLedger
* Restore code/ui-before copies until the Bazel magic is figured out
We need to make the template code a dependency in the Bazel rule as
otherwise we can't find the files in the docs build.
* Update create-daml-app/readme and make templates/readme more detailed
* Use jsx comments for docs markers so they don't show up in the app
* Use com.daml as groupId for all artifacts
CHANGELOG_BEGIN
[SDK] Changed the groupId for Maven artifacts to ``com.daml``.
CHANGELOG_END
* Add 2 additional maven related checks to the release binary
1. Check that all maven upload artifacts use com.daml as the groupId
2. Check that all maven upload artifacts have a unique artifactId
* Address @cocreature's comments in https://github.com/digital-asset/daml/pull/5272#pullrequestreview-385026181
Contributes to #4194.
Closes#4231.
Closes#5022.
CHANGELOG_BEGIN
- [Ledger API] The protobuf fields ledger_effective_time and maximum_record_time have been removed from
command submission. These fields were previously deprecated following the introduction
of a new ledger time model. See issue `#4194 <https://github.com/digital-asset/daml/issues/4194>`__.
[Java Bindings] removed the usage of ledgerEffectiveTime and
maximumRecordTime, and instead added minLedgerTimeAbsolute and
minLedgerTimeRelative in CommandSubmissionClient and CommandClient
CHANGELOG_END
* remove `src` subdir from codgen command
If you don't do this, running `yarn install` will complain:
```
error Couldn't find package "@daml-ts/create-daml-app-0.1.0@0.13.55" required by "create-daml-app@0.1.0" on the "npm" registry.
```
This was with yarn v1.22.4 - can someone please double-check this.
* Update codegen command and some surrounding explanation
Unfortunately also removed a bunch of trailing whitespace due to my
editor settings, which is fine but makes reviewing harder :(
changelog_begin
changelog_end
* Warn that workspaces run build takes ages
Co-authored-by: Rohan Jacob-Rao <rohanjr@gmail.com>
