vapor/template

Used by Vapor Toolbox’s new project command

template's Issues

Docker repository name case error

When following the hello world docs, you're prompted to use the name Hello (note the uppercase "H") as the project title. However, the name is interpolated into the docker-compose file under the image: key, and Docker image names can not include uppercase characters.

Steps to reproduce (using the latest version of Vapor):

$ vapor new Hello
$ cd Hello
$ docker-compose build
# ERROR: invalid reference format: repository name must be lowercase

A possible resolution would be to simply lowercase the name in the docker-compose file. I've done this manually and it seems to work - but I'm new to Vapor so I'm not sure if there are other implications. If this would work as a resolution, I'm happy to try and submit a PR.

Leaf template compiler issues

Describe the bug

If you create a new Vapor project with Leaf and no Fluent, then the project generates incorrectly.

To Reproduce

$ vapor new test-project
Cloning template...
name: test-project
Would you like to use Fluent?
y/n> n
fluent: No
Would you like to use Leaf?
y/n> y
leaf: Yes
Generating project files
...

routes.swift

import Vapor

func routes(_ app: Application) throws {
    app.get { req in
        return req.view.render("index", ["title": "Hello Vapor!"])
    }app.get { req in // this block shouldn't be here
        return "It works!"
    }

    app.get("hello") { req -> String in
        return "Hello, world!"
    }
}

configure.swift (no app.views.use(.leaf))

import Leaf
import Vapor

// configures your application
public func configure(_ app: Application) throws {
    // uncomment to serve files from /Public folder
    // app.middleware.use(FileMiddleware(publicDirectory: app.directory.publicDirectory))

    // register routes
    try routes(app)
}

Expected behavior

The project should compile after being generated, and should be setup correctly to use Leaf.

Environment

vapor: stable 18.3.3 (bottled), HEAD
xcode: 13.2.1 and 13.3 tested
macos: monterey 12.1

Additional context

has existed for quite a while, only just raising it

Add vapor user (non-root) to Dockerfile

Best to introduce a non-root user to the Dockerfile to execute the app.

Generating Templates Failing

See https://github.com/vapor/template/actions/runs/2263925985

Fluent drivers do not populate creating an invalid Package.swift

Creating a new project from the template does not populate the Fluent Driver correctly.

Choosing Postgres when running new vapor/toolbox, I expect:

.package(url: "https://github.com/vapor/fluent-postgres-driver.git", from: "2.0.0-beta")

but instead we get"

.package(url: "https://github.com/vapor/fluent--driver.git", from: "-beta")

Also reported in vapor/toolbox#279

MongoDB - Service 'db' is undefined.

Hello, when I create a new project with a mongoDB database, running docker-compose build gives me the following error:

ERROR: Service 'app' depends on service 'db' which is undefined.

To Reproduce

Here is the sequence of commands I used.

vapor new project-name
y (Fluent: yes)
4 (db: Mongo)
n (Leaf: no)
cd project-name/
docker-compose build

Expected behavior

I don't know much about Docker, but I think the project should build "out of the box".
Maybe related to issue #31.

Environment

• Vapor Framework version: 4.45.5
• Vapor Toolbox version: 18.3.3
• OS version: macOS 11.3.1 (arm64)

Dockerfile Failing to Build on First Try

Describe the bug

When the project doesn't have a Package.resolved. Docker Desktop on Mac fails to build the project on Dockerfile line 20:

...
RUN swift package resolve --skip-update \
        "$([ -f ./Package.resolved ] && echo "--force-resolved-versions" || true)"
...

This is the build log:

[+] Building 3.0s (14/22)                                                                                           docker:desktop-linux
 => [app internal] load .dockerignore                                                                                               0.0s
 => => transferring context: 58B                                                                                                    0.0s
 => [app internal] load build definition from Dockerfile                                                                            0.0s
 => => transferring dockerfile: 3.26kB                                                                                              0.0s
 => [app internal] load metadata for docker.io/library/swift:5.9-jammy-slim                                                         2.6s
 => [app internal] load metadata for docker.io/library/swift:5.9-jammy                                                              2.4s
 => [app build  1/12] FROM docker.io/library/swift:5.9-jammy@sha256:a13d1eff9d1639c967c2c1f28740328f57cde4caaf979d07e86811cbaefdd8  0.0s
 => [app internal] load build context                                                                                               0.0s
 => => transferring context: 7.23kB                                                                                                 0.0s
 => [app stage-1 1/5] FROM docker.io/library/swift:5.9-jammy-slim@sha256:3beefe3ea2e54d49d11a4f9e54769268616e8ee5a26597dc0af15497c  0.0s
 => CACHED [app stage-1 2/5] RUN export DEBIAN_FRONTEND=noninteractive DEBCONF_NONINTERACTIVE_SEEN=true     && apt-get -q update    0.0s
 => CACHED [app stage-1 3/5] RUN useradd --user-group --create-home --system --skel /dev/null --home-dir /app vapor                 0.0s
 => CACHED [app stage-1 4/5] WORKDIR /app                                                                                           0.0s
 => CACHED [app build  2/12] RUN export DEBIAN_FRONTEND=noninteractive DEBCONF_NONINTERACTIVE_SEEN=true     && apt-get -q update    0.0s
 => CACHED [app build  3/12] WORKDIR /build                                                                                         0.0s
 => CACHED [app build  4/12] COPY ./Package.* ./                                                                                    0.0s
 => ERROR [app build  5/12] RUN swift package resolve --skip-update "$([ -f ./Package.resolved ] && echo "--force-resolved-version  0.4s
------                                                                                                                                   
 > [app build  5/12] RUN swift package resolve --skip-update "$([ -f ./Package.resolved ] && echo "--force-resolved-versions" || true)":
0.357 error: dependency '' was not found
------
failed to solve: process "/bin/sh -c swift package resolve --skip-update \"$([ -f ./Package.resolved ] && echo \"--force-resolved-versions\" || true)\"" did not complete successfully: exit code: 1

Note that the build goes beyond line 20 when Dockerfile reverts to the parent of commit 6563d51, which has the following line instead.

...
RUN swift package resolve --skip-update
...

To Reproduce

Steps to reproduce the behavior:

1. Create a new Vapor App with vapor new my-dockerized-app and say no to everything when prompted.
2. cd dockerized-app
3. docker-compose build

Expected behavior

We should not see an error failing.

Environment

• Vapor Framework version: from: "4.83.1", can't give exact because Package.resolved doesn't exist
• Vapor Toolbox version: 18.7.4
• OS version: macOS 13.4.1

Additional context

About the Docker I'm using on the Mac:
Docker Desktop 4.24.0 (122432)
Engine: 24.0.6
Compose: v2.22.0-desktop.2
Credential Helper: v0.7.0
Kubernetes: v1.27.2

Dockerfile is missing Swift runtime dependencies, causing runtime crashes

The Swift runtime dynamically loads libcurl4 and libxml2 for FoundationNetworking and FoundationXML, respectively — the --static-swift-stdlib build option can't include those libraries in the binary so the runtime will crash at load, e.g:

./Run: error while loading shared libraries: libcurl.so.4: cannot open shared object file: No such file or directory

While a simple "hello world" Vapor app will work without libcurl4 and libxml2, I don't think omitting them was deliberate. [Correction: It was deliberate.]. Rather, like omitting tzdata(#75), this was probably an unintended side effect of changing the base run image to ubuntu:focal in #61 instead of using a (heavier) official Swift "slim" image as the base (e.g. swift:5.6-focal-slim).

For further reference:

• Deps in the official Swift "slim" image:
  https://github.com/apple/swift-docker/blob/a34976e/5.6/ubuntu/20.04/slim/Dockerfile#L5

• Swift on Server: Packaging Applications for Deployment:
  https://github.com/swift-server/guides/blob/main/docs/packaging.md

Environment

• Vapor Framework version: 4.62.0
• Vapor Toolbox version: 18.5.1
• OS version: macOS 12.4 host; Ubuntu Focal guest

ERROR [build 9/12] RUN cp "$(swift build --package-path /build -c release --show-bin-path)/App" ./

Describe the bug

I'm having problems building the project.

To Reproduce

Steps to reproduce the behavior:

=> [internal] load build definition from Dockerfile 0.0s
=> => transferring dockerfile: 3.90kB 0.0s
=> [internal] load .dockerignore 0.0s
=> => transferring context: 58B 0.0s
=> [internal] load metadata for docker.io/library/swift:5.9-jammy-slim 0.8s
=> [internal] load metadata for docker.io/library/swift:5.9-jammy 0.7s
=> [build 1/12] FROM docker.io/library/swift:5.9-jammy@sha256:d1a20a7ca0272bc0313a443b313762e465bd657674e41fbd06a06740a389a84e 0.0s
=> [internal] load build context 0.1s
=> => transferring context: 71.90kB 0.1s
=> [stage-1 1/5] FROM docker.io/library/swift:5.9-jammy-slim@sha256:9809396932ec79fd891d3d7beb37c666b76bf9b4e3319142dcb5eed4b19629e0 0.0s
=> CACHED [build 2/12] RUN export DEBIAN_FRONTEND=noninteractive DEBCONF_NONINTERACTIVE_SEEN=true && apt-get -q update && apt-get -q dist-upgrade 0.0s
=> CACHED [build 3/12] WORKDIR /build 0.0s
=> CACHED [build 4/12] COPY ./Package.* ./ 0.0s
=> CACHED [build 5/12] RUN swift package resolve --skip-update $([ -f ./Package.resolved ] && echo "--force-resolved-versions" || true) 0.0s
=> CACHED [build 6/12] COPY . . 0.0s
=> CACHED [build 7/12] RUN swift build -c release --static-swift-stdlib -Xlinker -u -Xlinker _swift_backtrace_isThunkFunction 0.0s
=> CACHED [build 8/12] WORKDIR /staging 0.0s
=> ERROR [build 9/12] RUN cp "$(swift build --package-path /build -c release --show-bin-path)/App" ./

Expected behavior

I still don’t understand what the problem could be

Environment

Last template of vapor for Docker

Add a trivial `async` example route to "bare" template

In considering vapor/vapor#2858, I wonder if a trivial async example route should be added to the "bare" template?

Having both a non-async and async example would illustrate a fundamental concept of Vapor, and provide an easy reference when the usage intent is to spin up a new app with a single endpoint that needs to call an async function. Vapor newcomers may also tend to generate using a "bare" template at the start of their learning (I know I did).

Or, the existing "It works!" and "Hello, world!" examples could be changed to use the async form if that form is generally encouraged for new apps?

I put some thought into what a trivial additional async example could be:

Task.sleep for a couple seconds

I like this option the most, followed by not doing any actual async work (the first alternative below). Having an await statement in the body of the function helps communicate the purpose of the example.

One drawback: a real app should never call Task.sleep, so this could inadvertently suggest a bad practice.

// Sources/App/routes.swift
import Vapor

func routes(_ app: Application) throws {
    app.get { req in
        return "It works!"
    }

    app.get("hello") { req -> String in
        return "Hello, world!"
    }

    app.get("async") { req async throws -> String in
        let nanosecondsPerSec: UInt64 = 1_000_000_000
        try await Task.sleep(nanoseconds: 2 * nanosecondsPerSec)
        return "Hello, async style!"
    }
}

Note: The global constant NSEC_PER_SEC is generally used to calculate a quantity of nanoseconds, but that's defined in libdispatch, which isn't really usable yet on non-Apple platforms (not that easily, at least). The nice time and duration APIs in Swift 5.7 will remove the need to calculate nanoseconds at all.

Alternative: Don't include any actual async work

// Sources/App/routes.swift
import Vapor

func routes(_ app: Application) throws {
    app.get { req in
        return "It works!"
    }

    app.get("hello") { req -> String in
        return "Hello, world!"
    }

    app.get("async") { req async throws -> String in
        return "Hello, async style!"
    }
}

This is still significantly differentiated from the non-async style "hello" function: it differs by the path segment, async throws in the signature, and the return value. That differentiation doesn't illustrate purpose, tho.

Alternative: Make a URL request (bad idea)

// Sources/App/routes.swift
import Vapor

func routes(_ app: Application) throws {
    app.get { req in
        return "It works!"
    }

    app.get("hello") { req -> String in
        return "Hello, world!"
    }

    app.get("async") { req async throws -> String in
        let urlRequest = URLRequest(url: URL(string: "http://example.com")!)
        let (data, response) = try await URLSession.shared.data(for: urlRequest)
        if let httpResponse = response as? HTTPURLResponse,
           httpResponse.statusCode != 200 {
            return "Error while fetching data"
        }
        return String(decoding: data, as: UTF8.self)
    }
}

A URL request is a familiar illustration, but this would depend on FoundationNetworking on non-Apple platforms, additionally needing:

#if canImport(FoundationNetworking)
import FoundationNetworking
#endif

And, the default Dockerfile omits FoundationNetworking's libcurl4 dependency to produce a smaller binary by default. The default Dockerfile should definitely successfully build the freshly generated app, and adding a heavy dependency to merely gain a usage example is a non-starter.

Making a real request to a hosted service in an app template can be inconsiderate to the host unless it's specifically meant for that kind of use. (I know example.com is meant for use in sample code, but I don't know whether it's meant for code that will actually be run.)

In some scenarios, good security policy may also block outgoing network traffic by default.

Lastly, the above URL request code doesn't compile on Swift 5.6 (I only tested linux). I didn't bother investigating why, but it seems the async variation of URLSession.shared.data(for:) was introduced in Swift 5.7, or perhaps the compiler's type inference just needs some helpful annotations. The example already isn't promising and isn't that trivial, and may be even more noisy once made to work on Swift 5.6.

LinuxMain is missing

Tests/LinuxMain.swift is missing and newbies can't run just created app on Linux and don't know what to do 🙂

Migrate the template to modern concurrency

Observed: the template project code uses EventLoopFuture for concurrency.

Expected: now that modern concurrency is available, the template project should use async/await and showcase the simplified code.

I think this is only about the Todo (Fluent) app example routes and migrations.

Support setting `MTELG.singleton` as Swift Concurrency executor

See apple/swift-nio#2564.
This is not tagged as of creating this issue.

Include a ReadMe file

Running vapor new <project name> generates boiler plates for a new project. It is a great starting point. However, it is surprising the boiler plate is missing a ReadMe file. It would be great to have one included in the initial project setup.

Blank new project can't parse Package.swift file

Hello,
after creating a new project with :

vapor-beta new todos

Wether or not we activate fluent we cannot build using the command line nor Xcode.
The same error alway shows before starting any build :
manifest parse error: target 'App' depends on an unknown package 'Vapor'

I've been creating many project for the last weeks (recording a video course) and this seems to happen since commit 9ab71c0

I'm available if you need more testing.
I'm on Catalina with the Xcode 11.4 beta and Swift 5.2
Thanks

Template app does not run

Describe the bug

Trying to run the docker container results in an error where the app container doesn't actually start.

To Reproduce

Steps to reproduce the behavior:

1. $ vapor new my-dockerized-app
2. $ cd my-dockerized-app
3. $ docker compose build
4. $ docker compose up app

Error:

Error response from daemon: unable to find user vapor: no matching entries in passwd file

Expected behavior

Both the app and the database begin running. Currently only the database begins running.

Environment

• Docker version: 20.10.17, build 100c701
• Vapor Framework version: 4.0.0
• Vapor Toolbox version: 18.5.1
• OS version: macOS 13.0

Vapor template docker-compose.yml crashes docker compose with mysterious go errors

Describe the bug

Vapor template docker-compose.yml contains directives that cause docker compose to crash with a mysterious error.

To Reproduce

vapor new template-app to create an app from template. Use Fluent with Postgres, no Leaf.

cd template-app

docker compose up

After building, Docker crashes with some mysterious Go errors.

Expected behavior

docker compose up should build and run the containers.

Environment

• macOS Big Sur 11.4 (20F71)
• Docker Desktop for Mac 3.5.2 (66501)
• Vapor Framework version: 4.48.2
• Vapor Toolbox version: 18.3.3

Additional context

The issue is caused by this piece of revert and migrate targets configuration in docker-compose.yml:

deploy:
      replicas: 0

When I comment these lines out, the containers do build and run, but I see blank non-running revert and migrate containers in my Docker Dashboard, which probably shouldn’t be like that.

CI should only build the toolbox once

Currently in the CI for testing the template we build the toolbox for each matrix variation. This is a bit wasteful and really we should build a statically linked toolbox in the first step and copy it to all the matrix options. This should cut down CI time

Add CI to test the template

Currently any PRs don't have CI, we should fix this

We should add some CI to test PRs that does the following:

• Build the toolbox
• Run vapor new for the various permutations
• Build the Docker container

We can base some of it on https://github.com/vapor/toolbox/blob/main/.github/workflows/test.yml#L8-L31

Add a VSCode devcontainer to the template repo

This could include a database setup depending on what (Fluent) Database driver is being used

Migrate to using static linking in the Dockerfile

Currently the template's Dockerfile compiles the application using dynamic linking and we copy that over to a slim image as we need the Swift runtime.

The current best practice (see https://github.com/swift-server/guides/blob/main/docs/packaging.md#docker) is to use static linking to improve start up times. This also means we can use a regular focal image instead of the slim images, saving some size

And don't use slim images

Reporting a vulnerability

Hello!

I hope you are doing well!

We are a security research team. Our tool automatically detected a vulnerability in this repository. We want to disclose it responsibly. GitHub has a feature called Private vulnerability reporting, which enables security research to privately disclose a vulnerability. Unfortunately, it is not enabled for this repository.

Can you enable it, so that we can report it?

Thanks in advance!

PS: you can read about how to enable private vulnerability reporting here: https://docs.github.com/en/code-security/security-advisories/repository-security-advisories/configuring-private-vulnerability-reporting-for-a-repository

docker-compose doesn't have a db service set when sqlite was selected during the template creation

I notice that when I create a fresh project while selecting sqlite as an option for db and run docker. The docker-compose won't build because db is not declared. Was something missing or need to be updated? Thanks

DockerFile using swift:5.7-jammy does not work

With DockerFile I'm unable to build with swift:5.7-jammy and ubuntu:jammy

Output error:

clang-13: error: unable to execute command: Killed
clang-13: error: linker command failed due to signal (use -v to see invocation)
[975/976] Linking Run
The command '/bin/sh -c swift build -c release --static-swift-stdlib' returned a non-zero code: 1

Environment

Docker

• Vapor Framework version: 4.0.0
• OS version: DockerFile

Additional context

I'm deploying to Google Cloud Build

heroku, docker, etc

support choosing whether Heroku or Docker support files should be included in a new project gen

Add CI to the template

When we get PRs for the template we should run some CI to ensure that things will work. This will involve running vapor new on the the branch/fork of the template too ensure the syntax is right and then building it.

We should build it using the generated Dockerfile to ensure that works as well

Enable autoMigrate for Fluent+SQLite based apps

Add repository Topics to enable discovery by topic search, e.g. "topic:template topic:vapor topic:vapor-4"

Is your feature request related to a problem?

It would be helpful to have a way to search for Vapor Templates.

For example: search "topic:template topic:vapor"

It would also be helpful if topic:vapor-4 were also added to differentiate current from legacy template.

Describe the solution you'd like

I would like to see topics vapor, vapor-4, and template added to the following repositories:

• https://github.com/vapor/template
• https://github.com/vapor/template-bare
• https://github.com/vapor/template-fluent-mysql
• https://github.com/vapor/template-fluent-postgres
• https://github.com/vapor/template-fluent-postgres-leaf
• https://github.com/vapor/template-fluent-sqlite

Thank you.

Public directory not added when using the template

When running vapor new... the Public directory is not included in the final generated project, it should be.

We probably just need to add the directory to the manifest.yml file

Docker buildx crashes when cross-compiling amd64 image on Apple Silicon Mac

Describe the bug

Using docker buildx build to cross-compile an amd64 image on an Apple Silicon Mac triggers a QEMU illegal instruction error during the swift package resolve step in the Dockerfile.

This seems to be related to this issue in Swift and this issue in Docker Desktop for Mac. Those issues are both closed, and yet the illegal instruction still occurs when building a Vapor project under Docker Desktop 4.16.2 for Mac.

To Reproduce

On an Apple Silicon Mac running Docker Desktop 4.16.2:

1. Create a new vapor project with vapor new buildx-test. You do not need fluent or leaf.
2. In the project folder, run docker buildx build --no-cache --platform linux/amd64 .

The build fails with this output:

docker buildx build --no-cache --platform linux/amd64 .

[+] Building 269.9s (15/24)
 => [internal] load .dockerignore                                                                                                 0.0s
 => => transferring context: 58B                                                                                                  0.0s
 => [internal] load build definition from Dockerfile                                                                              0.0s
 => => transferring dockerfile: 2.78kB                                                                                            0.0s
 => [internal] load metadata for docker.io/library/ubuntu:jammy                                                                   1.8s
 => [internal] load metadata for docker.io/library/swift:5.7-jammy                                                                1.8s
 => [auth] library/ubuntu:pull token for registry-1.docker.io                                                                     0.0s
 => [auth] library/swift:pull token for registry-1.docker.io                                                                      0.0s
 => CACHED [build  1/12] FROM docker.io/library/swift:5.7-jammy@sha256:e1da6de0a96b09438cfff68e7ab757eca073102fb34b5eaa637249545  0.0s
 => => resolve docker.io/library/swift:5.7-jammy@sha256:e1da6de0a96b09438cfff68e7ab757eca073102fb34b5eaa63724954536e9897          0.0s
 => [internal] load build context                                                                                                 0.0s
 => => transferring context: 40.24kB                                                                                              0.0s
 => [stage-1 1/5] FROM docker.io/library/ubuntu:jammy@sha256:9a0bdde4188b896a372804be2384015e90e3f84906b750c1a53539b585fbbe7f     0.0s
 => => resolve docker.io/library/ubuntu:jammy@sha256:9a0bdde4188b896a372804be2384015e90e3f84906b750c1a53539b585fbbe7f             0.0s
 => [build  2/12] RUN export DEBIAN_FRONTEND=noninteractive DEBCONF_NONINTERACTIVE_SEEN=true     && apt-get -q update     && ap  38.9s
 => [build  3/12] WORKDIR /build                                                                                                  0.0s
 => [build  4/12] COPY ./Package.* ./                                                                                             0.0s
 => [build  5/12] RUN swift package resolve                                                                                     198.2s
 => [build  6/12] COPY . .                                                                                                        0.0s
 => ERROR [build  7/12] RUN swift build -c release --static-swift-stdlib                                                         30.8s
------
 > [build  7/12] RUN swift build -c release --static-swift-stdlib:
#0 13.67 error: 'swift-algorithms': Invalid manifest
#0 13.67 qemu: uncaught target signal 4 (Illegal instruction) - core dumped
------
WARNING: No output specified with docker-container driver. Build result will only remain in the build cache. To push result image into registry use --push or to load image into docker use --load
WARNING: failed to get git remote url: fatal: No remote configured to list refs from.
Dockerfile:26
--------------------
  24 |
  25 |     # Build everything, with optimizations
  26 | >>> RUN swift build -c release --static-swift-stdlib
  27 |
  28 |     # Switch to the staging area
--------------------
ERROR: failed to solve: process "/dev/.buildkit_qemu_emulator /bin/sh -c swift build -c release --static-swift-stdlib" did not complete successfully: exit code: 1

Expected behavior

The docker buildx build command should produce a cross-platform image without error.

Environment

• Vapor Framework version: 4.69.2
• Vapor Toolbox version: 18.6.0
• OS version: macOS 13.2.1

Additional context

I have had some luck getting builds to work by inserting QEMU_CPU=max into the RUN swift commands in the Dockerfile and by prefixing my docker buildx build command with this environment variable. However, the results are inconsistent, and I'm having trouble narrowing down exactly where this environment variable is needed to produce reliable builds.