Data can often be messy and cleaning it up falls on the shoulders of you, the developer. It’s also easy to search StackOverflow for compl...development
Releasing new versions from continuous integration, rather than someone’s machine in a team environment is a great way to release new versions of npm packages in a predicable and controlled manner.
Here’s a quick runthrough for publishing an npm package from TeamCity:
We’ll need the build itself setup on TeamCity. For us, we’re currently following a
build.cmd philosophy for our projects. An example
build.cmd looks like this:
@echo Off pushd %~dp0 setlocal :Build call npm install if %ERRORLEVEL% neq 0 goto BuildFail call npm run build if %ERRORLEVEL% neq 0 goto BuildFail call npm run validate if %ERRORLEVEL% neq 0 goto BuildFail call npm pack if %ERRORLEVEL% neq 0 goto BuildFail goto BuildSuccess :BuildFail echo. echo *** BUILD FAILED *** goto End :BuildSuccess echo. echo *** BUILD SUCCEEDED *** goto End :End echo. popd exit /B %ERRORLEVEL%
Note the usage of
npm pack. This generates the necessary
.tgz artifact for the package that we can publish to npm.
Simply setup TeamCity to run your build.cmd, or however you want to setup your build.
The important point is ensuring the build artifacts include the
Now that there’s a working build generating the necessary artifact, we can create a build step to publish the package. This relies on the build script for the
Here’s a runthrough of the various options to configure:
ritter-jekyllto the name of your npm package):
@echo Off call npm config set "//registry.npmjs.org/:_authToken" "%npm_auth_token%" echo Before publish... for /f %%%%i in ('dir ritter-jekyll-*.tgz /b') do set PACKAGE=%%%%i call echo Publishing %%PACKAGE%% ... call npm publish %%PACKAGE%% call npm config delete "//registry.npmjs.org/:_authToken"
Now, you’re ready to deploy the latest version of your package from the
master branch. And, subsequent version updates will be automatically published by TeamCity as they reach