Today we are delighted to introduce Dagger 0.4.0, featuring service containers, secrets scrubbing, and more.

##### Service containers

Service containers have been one of the most requested features. They are now finally available. This feature enables you to run network services - like databases or webapps - as ephemeral containers, directly inside a Dagger pipeline.

Some common use cases for this new feature are:

* Run a test database
* Run end-to-end integration tests
* Run sidecar services

Service containers come with the following built-in features:

* Service containers are started just-in-time, de-duplicated, and stopped when no longer needed
* Service containers are health checked prior to running clients
* Service containers are given an alias for the client container to use as its hostname

###### Using service containers

Binding a service to a container expresses a dependency: the service container needs to be running when the client container runs. The bound service container is started automatically whenever its client container runs.

Here's an example of creating an HTTP service and fetching from it:

<iframe src="https://play.dagger.cloud/embed/pQoE-5_0Ghg" className="embed"> </iframe>

Here, the `WithExposedPort()` method sets the ports that the container will listen on. Dagger checks the health of each exposed port prior to running any clients that use the service, so that clients don't have to implement their own polling logic.

Want to learn more about how services work in Dagger? [Check out our documentation](https://docs.dagger.io/757394/use-service-containers).

##### Secrets scrubbing

Dagger now automatically scrubs secrets from its various logs and output streams. This ensures that sensitive data does not leak - for example, in the event of a crash. This applies to secrets stored in both environment variables and file mounts.

Here's an example that demonstrates this in action:

```go
package main

import (
	"context"
	"fmt"
	"os"

	"dagger.io/dagger"
)

func main() {
	cleanupEnv := setDemoHostEnv("my_secret_file")
	defer cleanupEnv()

	ctx := context.Background()
	// create Dagger client
	client, err := dagger.Connect(ctx)
	if err != nil {
		panic(err)
	}
	defer client.Close()

	secretEnv := client.Host().EnvVariable("MY_SECRET_ENV").Secret()
	secretFile := client.Host().Directory(".").File("my_secret_file").Secret()

	output, err := client.Container().
		From("alpine@sha256:e2e16842c9b54d985bf1ef9242a313f36b856181f188de21313820e177002501").
		WithSecretVariable("MY_SECRET_ENV", secretEnv).
		WithMountedSecret("/my_secret_file", secretFile).
		WithExec([]string{"sh", "-c", `echo -e "env secret data: $MY_SECRET_ENV || secret file data: "; cat /my_secret_file`}).
		Stdout(ctx)

	if err != nil {
		panic(err)
	}

	fmt.Println(output)
}

func setDemoHostEnv(hostFilePath string) (cleanup func() error) {
	// Setting a test host environment variable
	const envName = "MY_SECRET_ENV"
	err := os.Setenv(envName, "Secret Env Content")
	if err != nil {
		panic(err)
	}

	// Setting a test host file
	const hostFileContent = "Secret File Content"
	err = os.WriteFile(hostFilePath, []byte(hostFileContent), 0o644)
	if err != nil {
		panic(err)
	}

	return func() error {
		return os.Remove(hostFilePath)
	}
}

```

The output will be:

```
env secret data: *** || secret file data: 
***
```

Instead of

```
env secret data: Secret Env Content || secret file data: 
Secret File Content
```

##### SDK Updates

We've also released new versions of our SDKs with support for all the new features in Dagger 0.4.0, plus various SDK-specific bug fixes and improvements.

For a complete list of improvements, refer to the changelog for each SDK:

* Go SDK 0.5.0 [changelog](https://github.com/dagger/dagger/releases/tag/sdk%2Fgo%2Fv0.5.0) and [documentation](https://pkg.go.dev/dagger.io/dagger)
* Node.js SDK 0.4.0 [changelog](https://github.com/dagger/dagger/releases/tag/sdk%2Fnodejs%2Fv0.4.0) and [documentation](https://docs.dagger.io/current/sdk/nodejs/reference/modules)
* Python SDK 0.4.0 [changelog](https://github.com/dagger/dagger/releases/tag/sdk%2Fpython%2Fv0.4.0) and [documentation](https://dagger-io.readthedocs.org/)

We look forward to releasing more features soon! Meanwhile, if you have feedback or would like to suggest new features or documentation, let us know on [Discord](https://discord.com/invite/dagger-io) or create a [GitHub issue](https://github.com/dagger/dagger/issues/new/choose).


Learn about the new features in Dagger 0.4: service containers, secrets scrubbing and SDK updates.

Dagger 0.4: service containers, secrets scrubbing, and more

The term "reproducible build" refers to a build process that produces identical results on every run. With a reproducible build process, the build outputs of each run behave identically and they can be verified (via checksum) to be bit-by-bit identical.

#### The Importance of Being Reproducible

Reproducible builds are important for a number of reasons:

* They provide a way to reliably connect build artifacts to source code. The same source code always produces the same build output, regardless of the build environment.
* They provide a way to verify build artifacts. Different people can independently build a piece of source code and verify that their checksums are identical and/or match those provided by the original developer.
* They improve software supply chain security. When builds are always consistent, externally-injected changes (such as malware or spyware) will be immediately visible in a bit-wise comparison of build outputs.

#### Different Inputs = Different Outputs

As you might expect, creating reproducible builds is harder than it sounds, because of the large number of variables involved in the usual build process. These variables include:

* the host operating system
* the host timezone and locale
* the host environment configuration
* the compiler and its configuration
* the versions and configurations of build dependencies, such as system or third-party libraries
* file timestamps
* [and](https://reproducible-builds.org/docs/archives/) [many](https://reproducible-builds.org/docs/randomness/) [more](https://reproducible-builds.org/docs/build-path/)...

Implementing a reproducible build strategy thus implies extreme and strict control over all the variables involved in the build...not an easy task!

**Dagger and Reproducible Builds**

While Dagger doesn't claim to solve reproducible builds, we are working towards making them easier to implement. 

* Dagger executes your pipelines entirely as [standard OCI containers](https://opencontainers.org/). Containerization helps to reduce build variance by isolating the build environment from the host filesystem and environment. Containerization also makes it easier to use deterministic [build paths](https://reproducible-builds.org/docs/build-path/) and provides mechanisms to audit the build environment.
* For builds that depend on external resources, Dagger supports mounting pinned versions of those external resources. For example, you can use Dagger’s support for Git [repositories](https://docs.dagger.io/api/reference/#definition-GitRepository) and [references](https://docs.dagger.io/api/reference/#definition-GitRef) to easily retrieve a snapshot of a source code repository at an exact commit.
* Dagger also addresses part of what the [Reproducible Builds website](https://reproducible-builds.org/) calls “the [biggest source of reproducibility issues](https://reproducible-builds.org/docs/timestamps/)”: file timestamps. With Dagger, you can force all entries within a directory to have the same creation/modification timestamps. This eliminates one of the most common causes of variation in the build process.

Here's an example of this in action:

```
c, _ := dagger.Connect(ctx, dagger.WithLogOutput(os.Stdout))

   gitTag := "v0.3.10"
   repo := c.Git("https://github.com/dagger/dagger.git").Tag(gitTag).Tree()
   daggerBinary := c.Container().From("golang:1.19-alpine3.17").
   	  WithMountedDirectory("/src", repo).
   	  WithEnvVariable("CGO_ENABLED", "0").
   	  WithWorkdir("/src").
   	  WithExec([]string{"go", "build", "-o", "dagger", "./cmd/dagger"}).
   	  File("dagger")

    defaultTimestamp, _ := c.Container().From("alpine:3.17").
   	  WithMountedFile("/dagger", daggerBinary).
   	  WithExec([]string{"stat", "-c", "%y %s", "/dagger"}).
   	  Stdout(ctx)

    fixedTimestamp, _ := c.Container().From("alpine:3.17").
   	  WithMountedFile("/dagger", daggerBinary.WithTimestamps(0)).
   	  WithExec([]string{"stat", "-c", "%y %s", "/dagger"}).
   	  Stdout(ctx)

    fmt.Println("defaultTimestamp:", defaultTimestamp)
    fmt.Println("fixedTimestamp:", fixedTimestamp)

```

**The Future**

Containerization, resource pinning and timestamp fixation are only a few aspects of a reproducible build strategy. Other areas where Dagger could potentially be helpful are:

* Support for the special [SOURCE_DATE_EPOCH](https://reproducible-builds.org/docs/source-date-epoch/) variable ([recently added to buildkit](https://github.com/dagger/dagger/issues/4680)) 
* Support for disabling internet access during container execution, thereby forcing the build to be more "hermetic"
* Support for verifying if files downloaded via HTTP match a given checksum 
* Support for fine-grained source policies or “source pinning” ([also recently added to buildkit](https://github.com/dagger/dagger/issues/4679))
* Support for [tools that help you identify what about your build isn't deterministic](https://reproducible-builds.org/tools/)

Do you need support for one of the issues mentioned above? Leave us a comment in the issue to let us know.  We look forward to continuing to improve the reproducible builds experience with Dagger.

Reproducible Builds with Dagger


A few months ago, we released a [Python SDK for Dagger](https://dagger.io/blog/python-sdk). This SDK makes it easy to develop CI/CD pipelines in Python and run them on any OCI-compatible container runtime. Since the release, we’ve been continuously updating the SDK by adding new features and making changes to improve the code quality. In this blog post, I’ll discuss the “why” and “how” of one of our most recent improvements: adopting Ruff as the linter for our Python code.

Ruff is a new Python linter that is very fast because it’s built in Rust. In its inaugural post [“Python tooling could be much, much faster”](https://notes.crmarsh.com/python-tooling-could-be-much-much-faster), [Charlie Marsh](https://twitter.com/charliermarsh) (Ruff’s creator) goes into more detail over how it works, tradeoffs, and implications, which I think is worth a read.

### Why Ruff?

Charlie was one of our early Python SDK testers before we [launched](https://dagger.io/blog/python-sdk). At the time I noticed he built a new tool and [checked it out](https://notes.crmarsh.com/python-tooling-could-be-much-much-faster). I found it interesting but, as an early project, it certainly didn’t cross my mind to use it in Dagger then.

A few weeks ago I came across a [tweet from Charlie](https://twitter.com/charliermarsh/status/1613198373594578946) noting that [Pandas](https://pandas.pydata.org/) was moving to Ruff and that caught my attention because Pandas is a very well known and popular Python project. I took another [look](https://github.com/charliermarsh/ruff) and saw that several other popular open-source projects were using it as well. Some of which I’ve used, like [FastAPI](https://github.com/tiangolo/fastapi), [Pydantic](https://github.com/pydantic/pydantic), [Sphinx](https://github.com/sphinx-doc/sphinx) and [Hatch](https://github.com/pypa/hatch).

There were other signs that  pointed to Ruff’s growing popularity, including a tweet where [PyPI](https://pypi.org/) (the Python packages repository) reported that the [project had become critical](https://twitter.com/charliermarsh/status/1618809642079105025) (i.e., a project in the top one percent of downloads over the previous six months).

I thought it was time to give Ruff a try in Dagger, not because I was looking to solve a specific problem, but because I was curious. During experimentation, I found enough benefits to make the switch.

### Adopting Ruff

The [Adopt Ruff PR](https://github.com/dagger/dagger/pull/4399/files) demonstrates both a reduction in dependencies and numerous code improvements to satisfy the linter. Below, I’ll expand a bit more on what I found were the main benefits.

#### Speed

The main advantage of Ruff is its speed, but it wasn’t the deciding factor because our [codebase](https://github.com/dagger/dagger/tree/main/sdk/python) is small, so linting time wasn’t a problem for us. Linting approximately 6500 lines of code in 40+ files used to take over 3 seconds. With Ruff, it takes approximately 0.03 seconds. That’s 100x faster.

The speed bump unexpectedly improved my productivity, because Ruff is fast enough to lint while editing code and provide immediate feedback. I used to run the linter in the terminal before committing, but Ruff has good documentation on supporting multiple environments and IDEs, which led me to set up [ruff-lsp](https://github.com/charliermarsh/ruff-lsp). Now, I get the warnings directly in my IDE, in real-time.

#### Dependency reduction

<div style="text-align:center;margin:40px 0px;">
    <img width="355" height="386" src="/img/219827583-695b3735-a8e5-48f9-a3fd-d448e0c2db23.png"></img>
    <p style="font-size:1.5rem;">diff in lint dependencies and commands in the <a style="font-size:1.5rem;" href="https://github.com/dagger/dagger/pull/4399/files">Adopt ruff PR</a></p>
</div>

Reducing dependencies always feels good. This was a major advantage for us.

Like many Python projects, Dagger was using [flake8](https://github.com/pycqa/flake8) and [isort](https://github.com/PyCQA/isort) to lint our codebase, as well as [autoflake](https://github.com/PyCQA/autoflake) to automatically fix a few linting violations during formatting. Flake8 has a pluggable architecture, which means you need to install quite a few plugins if you want to cover more ground, adding to your dependencies.

Ruff has near feature parity with these tools and is implementing many popular flake8 plugins in its codebase, making them “batteries included”. So, your project has fewer dependencies, you get many more linting rules for free, and it all still runs faster.

#### Code improvements

With flake8, and even Ruff, you usually specifically select which rules you want to use for linting. With Dagger, I decided to take the opposite approach - excluding the ones I didn’t want but allowing everything else.

This means that when Ruff is updated (which usually results in more checks due to the implementation of more flake8 plugins), linting is likely to fail. But I like it that way since I get notified by GitHub’s [dependabot](https://docs.github.com/en/code-security/dependabot) automatically that there’s code that could probably be improved by following some best practice or avoiding a security or potential bug issue. That’s what linters are for.

Compared to the stagnation we had before, having only a short set of linter rules enabled, this is an easy win for continually improving the codebase.

### Future steps

- Ruff is released frequently. This is good but puts a burden on maintenance. I get a new [dependabot PR](https://github.com/dagger/dagger/pull/4546) for it almost daily but can’t review them everyday. Dependabot closes the previous PR and opens a new one so there’s only ever one to deal with at any time, but I don’t like to ignore it in the meantime. I’m thinking about changing the schedule frequency from daily to weekly and reserving a little bit of time each week to review all updates.
- We still use [black](https://github.com/psf/black) to format code. It’s also tied to the lint step because I consider it a linting violation if black has changes to make. So in both the lint and format steps, we’re only using Ruff and black now. It would be great to only use Ruff for both steps. It seems [others want it too](https://github.com/charliermarsh/ruff/issues/1904) and that some experimentation has started on this, so it may become a reality soon.

### Conclusion

Why not use a more performant language to write tooling for Python? Ruff started as a proof-of-concept to [question the status quo](https://notes.crmarsh.com/python-tooling-could-be-much-much-faster). On one hand, it limits contribution by pythonistas but on the other hand, as a user of the tool, I do appreciate the fast execution and reduction of dependencies while still getting many more rules in return.

I’m looking forward to seeing how this project evolves and if it inspires even more performant tools to emerge as well.


Adopting Ruff for Dagger’s Python SDK

It's the start of a new year and to celebrate, we've been hard at work adding improvements to Dagger. Our latest release of the Dagger is v0.3.10, which incorporates two significant new features for status reporting and container metadata management.

### Dagger 0.3.10 Highlights

#### New Pipeline API

Dagger now provides a [Pipeline API](https://docs.dagger.io/api/reference/#query-pipeline), which enables developers and operators to programmatically group related operations together into "pipelines" for status reporting and visualization purposes (e.g. logs). This new feature makes it easier to cut through the "noise" of your CI's daily operations and improves visibility of specific operations or events.

Pipelines are hierarchical and can contain any number of child pipelines. Here's an example of using this new API in Go:

```go
// `c` belongs to the root pipeline at this point
c, _ := dagger.Connect(ctx)

// everything using `c` is nested under the `sdk` pipeline from now on
c = c.Pipeline("sdk")

nodejs :=
c.Pipeline("nodejs").Container().From("node:16").WithExec([]string{"yarn install"}) // pipeline is `sdk/nodejs`
lint := nodejs.Pipeline("lint").WithExec([]string{"yarn lint"}) // 
pipeline is `sdk/nodejs/lint`
test := nodejs.Pipeline("test").WithExec([]string{"yarn test"}) // 
pipeline is `sdk/nodejs/test`
```

#### Support for Container Metadata

Dagger now allows developers to add and manage container metadata via support for the [Dockerfile LABEL instruction](https://docs.docker.com/engine/reference/builder/#label). For any given container, you can now add a label (withLabel), remove a label (withoutLabel), print the value of a label (label) or print all the labels (labels).

Here's an example of using these new methods in Go:

```go
c, _ := dagger.Connect(ctx, dagger.WithLogOutput(os.Stdout))

gitTag := "v0.3.10"
repo :=
c.Git("https://github.com/dagger/dagger.git").Tag(gitTag).Tree()
daggerBinary := c.Container().From("golang:1.19-alpine3.17").
    WithMountedDirectory("/src", repo).
    WithEnvVariable("CGO_ENABLED", "0").
    WithWorkdir("/src").
    WithExec([]string{"go", "build", "-o", "dagger", "./cmd/dagger"}).
    File("dagger")

publishTarget := "fake.registry.invalid/test/publish:latest"
labelName := "dagger.version"
_, err := c.Container().From("gcr.io/distroless/static-debian11")
     .WithFile("/bin/dagger", daggerBinary).
     WithLabel(labelName, gitTag).
     Publish(ctx, publishTarget)
if err != nil {
    return err
}

labelVal, err := c.Container().From(publishTarget).Label(ctx, labelName)
if err != nil {
    return err
}
fmt.Println(labelName, "=", labelVal)
```

### SDK Highlights

We've also released new versions of our SDKs with support for all the new features in Dagger 0.3.10, plus various SDK-specific bug fixes and improvements.

#### Targeted Builds

All SDKs now have an improved Build() method that allows users to build a particular target in a multi-stage Dockerfile. This was a frequently requested feature from the community. Here's an example using the Nodejs SDK:

```javascript
import { connect } from "@dagger.io/dagger";

connect(async (client) => {
    const src = client
    .directory()
    .withNewFile("Dockerfile",
      `FROM node:16-slim AS base
       CMD echo "base"
       FROM base AS stage1
       CMD echo "stage1"
       FROM base AS stage2
       CMD echo "stage2"
       `
    )

      const output = await client.container().build(src, { target: 
  "stage1" }).withExec([]).stdout()

    // This will output "stage1"
    console.log(output)
  
  }, { LogOutput: process.stdout })
```

#### Improved Error Messages

The Python SDK now provides more verbose error messages whenever a Dagger session connection cannot be established. This makes it quicker and easier to debug failed sessions. Here's an example:

Before

```
dagger.exceptions.ProvisionError: Dagger engine failed to start
```

After

```
dagger.exceptions.SessionError: Dagger engine failed to start:Command 
'dagger/dagger-0.3.9 session' returned non-zero exit status 1.Error: 
failed to run container: docker: Cannot connect to the Docker daemon 
at unix:///var/run/docker.sock.Is the docker daemon running?.
```

#### Other Improvements

For a complete list of improvements, refer to the changelog for each SDK:

* Go SDK 0.4.4 [changelog](https://github.com/dagger/dagger/releases/tag/sdk%2Fgo%2Fv0.4.4) and [documentation](https://pkg.go.dev/dagger.io/dagger)
* Node.js SDK 0.3.2 [changelog](https://github.com/dagger/dagger/releases/tag/sdk%2Fnodejs%2Fv0.3.2) and [documentation](https://docs.dagger.io/current/sdk/nodejs/reference/modules)
* Python SDK 0.3.1 [changelog](https://github.com/dagger/dagger/releases/tag/sdk%2Fpython%2Fv0.3.1) and [documentation](https://dagger-io.readthedocs.org/)

### New Documentation

Interested in using Dagger with GitHub? We've added a new end-to-end tutorial that teaches you how to use a Dagger pipeline to continuously build and deploy a Node.js application with GitHub Actions.

[Read the tutorial](https://docs.dagger.io/sdk/nodejs/620941/github-google-cloud/)

\
We look forward to releasing more features and documentation soon! In the meanwhile, if you have feedback or would like to suggest new features or documentation, let us know on [Discord](https://discord.com/invite/dagger-io) or create a [GitHub issue](https://github.com/dagger/dagger/issues/new/choose).

Dagger 0.3.10: New pipeline API, support for container metadata, and more

Dagger's approach to building CI/CD pipelines is unique. Our [SDKs](https://docs.dagger.io/#which-sdk-should-i-use) let you develop your pipelines as code, in a programming language you already know, and then execute those pipelines as standard [OCI containers](https://opencontainers.org/). This approach is both supremely portable and consistent (because your pipeline runs the same way locally and in a remote CI environment) and it has the added bonus of compatibility with the existing Docker ecosystem.

One of the most common questions users ask when first encountering Dagger is, "I already have a Dockerfile, why should I use Dagger?" And the answer (like most good answers) depends very much on the intended use case.

### Usage Scenarios

It's true that for most small and medium size projects without complex CI/CD needs, a Dockerfile can (and does) get the job done. But there are a number of scenarios where replacing a Dockerfile with a Dagger pipeline can yield significant benefits. Here are a few:

* Replacing monolithic CI dependency images: Sometimes, teams maintain one giant everything-including-the-kitchen-sink Dockerfile containing multiple dependencies so they only have to reference one image (like `myorg/ci`) in all their CI pipelines. Building and pushing these Dockerfiles becomes quite a chore, and teams must also deal with registry rate limits (if using a public registry) or maintain a private registry instead. Dagger lets you maintain images purely as code, so you never have to worry about building and pushing gigantic monolithic CI images.
* Sharing data between CI pipelines and application code: Since your Dagger pipeline is usually written in the same language as your application, it's much easier to share data between the two. For example, if you have a constant (like an image name) that you use in your actual production codebase, you can import it directly into your CI code rather than attempting to pass it as a Dockerfile argument.
* Greater re-usability and abstraction: Dagger lets you use general purpose programming languages and therefore supports more re-usability and abstraction. You can access native control structures like conditionals and loops, benefit from the language's existing testing tools, and add new functionality or integrate with third-party services using community extensions or packages. These operations are either extremely awkward or unsupported in the standard Dockerfile model, but very easy with Dagger. By the same token, Dagger pipelines also benefit from static typing and easier refactoring.
* Gradually rewriting a legacy Dockerfile: Sometimes you are stuck with a Dockerfile that is both very important, and painful to use. Everyone knows it should be replaced with something more powerful, ideally using a real programming language - but rewriting it all at once, without breaking compatibility, is too hard, so it never happens. Since Dagger can natively run Dockerfiles with full compatibility, it’s easy to wrap your existing Dockerfile in a Dagger pipeline, and gradually refactor it over time, without breaking your team’s workflow.

### Getting Started

If you've struggled with one or more of these scenarios, or if you're just curious about how it all works, we've put together a brief [guide on replacing a Dockerfile with a Dagger pipeline](https://docs.dagger.io/205271/replace-dockerfile). This guide explains how to use the Dagger Go SDK to perform all the same operations that you would typically perform with a Dockerfile. 

It illustrates the process by replacing the Dockerfile for the popular open source Memcached caching system with a Dagger Go pipeline and covers the following common tasks:

* Create a Dagger client in Go
* Write a Dagger pipeline in Go to:
* Configure a container with all required dependencies and environment variables
* Download and build the application source code in the container
* Set the container entrypoint
* Publish the built container image to Docker Hub
* Test the Dagger pipeline locally

We hope you find this guide useful and look forward to releasing more such guides soon! In the meanwhile, if you have feedback or would like to suggest new features or documentation, let us know in [Discord](https://discord.com/invite/dagger-io) or create a [GitHub issue](https://github.com/dagger/dagger/issues/new/choose).

Replacing your Dockerfile with Go code

It's been three weeks since we released the [Dagger Node.js SDK 0.1.0](https://dagger.io/blog/nodejs-sdk). Since then, we've received many questions and suggestions from the community and we've incorporated several of them in our latest release, the Dagger Node.js SDK 0.3.0.

This version introduces two breaking API changes. However, we believe the improved API allows you to write much shorter code, which is significantly better in the long run.

[Get Started](https://docs.dagger.io/sdk/nodejs/783645/get-started)

### Dagger Node.js SDK 0.3.0 Highlights

#### Optional parameters as objects

You can now use objects for optional parameters. 

* Required parameters can be provided directly to functions as positional arguments.
* Optional parameters can be provided through an object that lets you mix and match the options you want. 

B﻿efore: 

```javascript
const source = await 
client.container().from(“alpine:16”).withExec([“echo”, “foo”], 
undefined, undefined, undefined, true)
```

A﻿fter: 

```
const source = await 
client.container().from('alpine').withExec(['echo', 'foo'], 
{experimentalPrivilegedNesting: true})
```

[Read the SDK documentation](https://docs.dagger.io/current/sdk/nodejs/reference/modules)

#### Less boilerplate

You no longer need to pass IDs, which makes the code you need to write much shorter. 

B﻿efore: 

```
const source = await client.host().directory(".").id()
const c = await client
    .container()
    .from("node:16")
    .withMountedDirectory("/src", source.id)
```

A﻿fter: 

```
const source = client.host().directory(“.”)
const c = await client
    .container()
    .from("node:16")
    .withMountedDirectory("/src", source)
```

[Read the SDK documentation ](https://docs.dagger.io/current/sdk/nodejs/reference/modules)

#### Centralized error handling

Debugging and error handling is faster and easier with new, more precise error messages and codes. 

B﻿efore: 

```
file:///home/user/src/demos/node_modules/@dagger.io/dagger/dist/provisioning/docker-provision/image.js:255
        	throw new Error("failed to read port from engine session");
              	^
Error: failed to read port from engine session
	at DockerImage.<anonymous> (file:///home/dolanor/src/demos/node_modules/@dagger.io/dagger/dist/provisioning/docker-provision/image.js:255:19)
	at Generator.next (<anonymous>)
	at fulfilled
```

A﻿fter: 

```
Error: buildkit failed to respond
file:///home/user/src/demos/node_modules/@dagger.io/dagger/dist/provisioning/docker-provision/image.js:262
        	throw new EngineSessionPortParseError("No line was found to parse the engine port");
              	^
EngineSessionPortParseError [EngineSessionPortError]: No line was found to parse the engine port
	at DockerImage.<anonymous> (file:///home/dolanor/src/demos/node_modules/@dagger.io/dagger/dist/provisioning/docker-provision/image.js:262:19)
	at Generator.next (<anonymous>)
	at fulfilled (file:///home/dolanor/src/demos/node_modules/@dagger.io/dagger/dist/provisioning/docker-provision/image.js:4:58)
	at processTicksAndRejections (node:internal/process/task_queues:95:5) {
  cause: undefined,
  code: 'D103'
}
```

[Learn more about the new error types](https://docs.dagger.io/current/sdk/nodejs/reference/modules/common_errors)

#### Improved filesystem API

We've added new methods to make it easier to work with the container filesystem

* `Container.WithDirectory`: returns the container plus a directory written at the given path.
* `Container.WithFile`: returns the container plus the contents of the given file copied to the given path.
* `Container.WithNewFile`: returns the container plus a new file written at the given path.

##### W﻿ithNewFile

B﻿efore: 

```
let textFile = fs.openSync("myTextFile", "w")
fs.writeFileSync(textFile, "my text content")

let packageFile = await client
    .host()
    .workdir(undefined, ["myTextFile"])
    .id()

await client
    .container()
    .from("node")
    .withMountedDirectory("/tmp/filedir", packageFile.id)
    .exec([ "cat", "/tmp/filedir/myTextFile" ])
    .stdout()
    .contents()
```

A﻿fter: 

```
await client
    .container()
    .from("node")
    .withNewFile("/tmp/filedir/myTextFile", { contents: "my text content" })
    .withExec([ "cat", "/tmp/filedir/myTextFile" ])
    .stdout()
```

[Read the SDK documentation](https://docs.dagger.io/current/sdk/nodejs/reference/classes/api_client_gen.Container)

We believe these changes bring the overall experience of using the SDK closer to what Node.js developers expect and use elsewhere, and also result in shorter and more readable code.

Thank you to the Dagger Community for your continuous and quick feedback. We look forward to releasing more features and documentation soon! In the meanwhile, if you have feedback or would like to suggest new features or documentation, let us know on [Discord](https://discord.com/invite/dagger-io) or create a [GitHub issue](https://github.com/dagger/dagger/issues/new/choose).

Dagger 0.6: New Terminal UI

Dagger 0.4: service containers, secrets scrubbing, and more

Reproducible Builds with Dagger

Adopting Ruff for Dagger’s Python SDK

Dagger 0.3.10: New pipeline API, support for container metadata, and more

Replacing your Dockerfile with Go code

Dagger Node.js SDK 0.3: API improvements, better error handling and less boilerplate