Build your project

April 21, 2026 · View on GitHub

The generated code is not enough to release at once and you need to update it for better user experience. Please follow the steps to check the code:

Build your project

After this finishes, you will see the generated code in src folder in your {PROJECT_ROOT}. Refer the development workflows guide for more details if you'd like to know more.

pnpm install
pnpm build --filter=<your-package-name>...

Customizing the generated code

If the generated code does not fit your needs, you can use the JavaScript customization workflow to make edits. This should only be done in coordination with the JavaScript architects. For more information, see the Modular (DPG) Customization Guide.

Generate CHANGELOG.md

Install js-sdk-release-tools

npm --prefix eng/tools/js-sdk-release-tools ci

After you build your package, run

npm --prefix eng/tools/js-sdk-release-tools exec --no -- changelog-tool <your-package-path>

Here is the example

npm --prefix eng/tools/js-sdk-release-tools exec --no -- changelog-tool sdk/advisor/arm-advisor

Improve README.md document

A minimal README.md is generated by TypeScript emitter and you could improve README.md file per your service. To learn more about README, see below example README file.

How to write test for DPG/RLC/MPG

In order to release it, we need to add some tests for it to make sure we are delivering high quality packages. After generation you will see a sampleTest.spec.ts file in your {PROJECT_ROOT}/test/public folder, which has an empty test and you could add/update test cases against your own services.

See the Javascript Codegen Quick Start for Test for information on how to write and run tests for the Javascript SDK.

  1. Write the test

    You could follow the basic RLC test interaction and recording example to write your test step by step.

    Also, you could refer to the below examples for more cases:

  2. Run the test

    Now, you can run the test like this. If you are the first time to run test, you need to set the environment variable TEST_MODE to record. This will generate recordings for your test they could be used in playback mode.

    On Linux, you could use export to set env variable:

    pnpm build --filter=${PACKAGE_NAME}...
export TEST_MODE=record && pnpm test # this will run live test and generate a recordings folder, you will need to submit it in the PR.

    On Windows, you could use SET:

    pnpm build --filter=${PACKAGE_NAME}...
SET TEST_MODE=record&& pnpm test # this will run live test and generate a recordings folder, you will need to submit it in the PR.

    You can also run the playback mode test if your apis don't have breaking changes and you've already done the recording before.

    On Linux, you could use below commands:

      pnpm build --filter=${PACKAGE_NAME}...
export TEST_MODE=playback && pnpm test # this will run live test and generate a recordings folder, you will need to submit it in the PR.

    On Windows, you can use:

    pnpm build --filter=${PACKAGE_NAME}...
SET TEST_MODE=playback&& pnpm test # this will run live test and generate a recordings folder, you will need to submit it in the PR.

How to write samples

We highly encourage you to write some valid samples for your customer to get start your service with libraries. You may author TypeScript samples under the samples-dev folder. For quick start, you can use sample-dev template as reference and update the relevant information for your service such as package-name, sample code, description, etc.

To learn more, you could refer to the below samples:

After the samples-dev folder change is finished, you will need to change the tsconfig.json to make sure the dev samples can be compiled and build correctly.

You will need to add this part to the compilerOptions of your tsconfig.json file so that the Samples engine could resolve the sample-dev package against the source code of the SDK.

    "paths": { "@azure/agrifood-farming": ["./src/index"] }

And change the "include" part to

  "include": ["./src/**/*.ts", "./test/**/*.ts", "samples-dev/**/*.ts"],

Then, we provide tools to automatically change it into workable samples in both TypeScript and JavaScript. And, you just need to add a sampleConfiguration in your package.json.

You will need to add a sample configuration section in your package.json file and put the following content into it.

  "//sampleConfiguration": {
    "productName": "A description of your services",
    "productSlugs": ["azure"],
    "disableDocsMs": true,
    "apiRefLink": "<the-link-to-your-service-on-learn.microsoft.com>"
  }

Now, you can generate both JavaScript and TypeScript workable samples with the following commands.

cd ${PROJECT_ROOT}
npx dev-tool samples publish -f

You will see the workable samples in the ${PROJECT_ROOT}/samples folder.

Format both the generated code and manual code

After you have finished the generation and added your own tests or samples, you can use the following command to format the code.

cd ${PROJECT_ROOT} && pnpm format

Also, we'll recommend you to run lint command to analyze your code and quickly find any problems.

cd ${PROJECT_ROOT} && pnpm lint

And we could use lint:fix if there are any errors.

cd ${PROJECT_ROOT} && pnpm lint:fix

How to create package

Now, we can use the exact same steps to build a releasable artifact.

pnpm update
pnpm build --filter=<your-package-name>...
cd <your-sdk-folder>
export TEST_MODE=record && pnpm test
pnpm pack

You may send this artifact to your customer if your services are still in private preview and some customers want to try it out.

Create/Update the ci.yaml

Now, if everything looks good to you, you can submit a PR in azure-sdk-for-js repo with all the changes you made above. Before you do that, you need to add/update the ci.yml file. Depends on whether there's already one in your package folder.

If there's no such file, then you can add the following template.

# NOTE: Please refer to https://aka.ms/azsdk/engsys/ci-yaml before editing this file.
trigger:
  branches:
    include:
      - main
      - release/*
      - hotfix/*
  paths:
    include:
      - sdk/purview/
pr:
  branches:
    include:
      - main
      - feature/*
      - release/*
      - hotfix/*
    exclude:
      - feature/v4
  paths:
    include:
      - sdk/purview/
extends:
  template: ../../eng/pipelines/templates/stages/archetype-sdk-client.yml
  parameters:
    ServiceDirectory: purview
    Artifacts:
      - name: azure-agrifood-farming # azure-agrifood-farming for DPG; azure-rest-agrifood-farming for RLC
        safeName: azureagrifoodfarming # azureagrifoodfarming for DPG; azurerestagrifoodfarming for RLC

Please change the paths.include value as your own project path, and change the Artifacts name and safeName into yours.

If there's already a ci.yml file in your project path, then the only thing you need to do is to add the Artifacts name and safeName of yours into that ci.yml.

Please notice the Artifacts name should align with your package name. Here, the package name is @azure/agrifood-farming so the relevant Artifacts name is azure-agrifood-farming.

Prepare PR

TypeScript emitter can only help you generate SDK code, there is something you need to update manually.

CHANGELOG.md

CHANGELOG can help customers know the change of new version quickly, so you need to update it according to the change of this new version. It is also necessary to update release date like 1.0.0-beta.1 (2022-11-11) (rough time is fine and no need to be very accurate).

Version Number

You shall update the version number according to semantic versioning rule.

Test recordings

After writing and running test cases, you need to push the recordings to assets repo. Please refer to push recording guide to push recordings.

Fix CI for PR

You may meet the CI failures after submitting the PR, so please refer to Troubleshoot CI Failure to fix it.

Resolve conflicts for PR

Latest changes to the main branch may introduce merge conflicts of pnpm-lock.yaml file to the PR, so please try to follow these steps to resolve conflicts:

  1. checkout to main branch and pull the latest code
  2. checkout the PR's branch
  3. run git merge main
  4. run git checkout origin/main pnpm-lock.yaml
  5. run pnpm install
  6. push your changes into your PR

If you meet other files' conflicts, you need to resolve them case by case.

Steps to check out the AutoPR branch locally

AutoPR is created by a bot based on the azure-sdk/azure-sdk-for-js repo. Since this is a different fork from Azure/azure-sdk-for-js, you cannot directly check out the branch or push changes to it via origin. Here are three solutions to check out the AutoPR branch locally.

Note for Options 2 & 3: Replace {REMOTE_NAME} with any name you prefer (e.g., azure-sdk), and {BRANCH_NAME} with the branch name shown in the AutoPR (e.g., sdkauto/@azure-arm-connectedcache-5699155).

This is the easiest way — no git commands needed. The GitHub Pull Requests extension can check out any PR branch directly in VS Code, including PRs from forks.

  1. Install the GitHub Pull Requests extension in VS Code if you haven't already.
  2. Open the GitHub Pull Requests panel from the Activity Bar (the GitHub icon).
  3. Find the AutoPR by its PR number or search by branch name.
  4. Click the Checkout button next to the PR.

VS Code will automatically fetch the branch from the fork and create a local tracking branch for you.

Option 2: Fetch the branch and create a local tracking branch

This option lets you make local commits and easily push them back to the remote branch.

  1. Add the remote (skip if already added): 
    git remote add {REMOTE_NAME} https://github.com/azure-sdk/azure-sdk-for-js.git
  2. Fetch the specific branch: 
    git fetch {REMOTE_NAME} {BRANCH_NAME}
  3. Create a local branch that tracks the remote branch: 
    git checkout -b {LOCAL_BRANCH_NAME} --track {REMOTE_NAME}/{BRANCH_NAME}

Full example:

git remote add azure-sdk https://github.com/azure-sdk/azure-sdk-for-js.git
git fetch azure-sdk sdkauto/@azure-arm-connectedcache-5699155
git checkout -b pr/azure-sdk/36933 --track azure-sdk/sdkauto/@azure-arm-connectedcache-5699155

Option 3: Fetch all branches and checkout

This option fetches all branches from the remote, which takes longer but is useful if you need to access multiple branches.

  1. Add the remote (skip if already added): 
    git remote add {REMOTE_NAME} https://github.com/azure-sdk/azure-sdk-for-js.git
  2. Fetch all branches from the remote: 
    git fetch {REMOTE_NAME}
  3. Checkout the branch: 
    git checkout {BRANCH_NAME}

Full example:

git remote add azure-sdk https://github.com/azure-sdk/azure-sdk-for-js.git
git fetch azure-sdk
git checkout sdkauto/@azure-arm-connectedcache-5699155

CC dpg-devs for review

Please add below comment in your PR to include dpg-devs to review your PR timely.

cc @Azure/dpg-devs for awareness

Release

Prepare your SDK for release. The necessary approvals, guidance for testing, documentation, and release pipelines is described in your release plan. More information about the Azure SDK Release Tool is here