New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add an option to publish a .tgz previously packed with npm pack
#4958
Comments
|
@asiffermann, Here are a few suggestions:
[1] |
|
Hi, The key part of my scenario is that I have two different pipelines: a build definition which creates the package (with the Build definitionCreate the packageCopy it in the build artifactsRelease definitionPipelineI cannot use the preconfigured publish commandI cannot use the custom commandThe minimatch pattern is not resolved, and I cannot select the external npm registry. My temporary fixSo, at the moment, I can only extract the package and then publish it. Hope it's clearer now! |
|
@asiffermann, In the near term, you should know that NPM 5+ doesn't support publishing a .tgz so be careful upgrading. In fact, I would recommend using the NPM tool installer in your release definition to ensure that you're using npm 3/4.x while the NPM issue gets resolved... hopefully. Keith |
|
@asiffermann, if supplied minimatch pattern matches several packages, would you expect all of them to be published or task should fail? @keithrob, do you have any rough ETA for this feature? I need it and considering doing it by myself. Is it worth to wait? |
|
@yrtimiD, |
|
Just to add I've got the same issue, in our instance we're building (packing) within a docker container but it's necessary (on-top of being a good idea) to publish from TFS because we need to authenticate with the registry. I'm going to use your workaround @asiffermann |
|
Everyone with the same issue should please Thumbs Up the original message box that describes the issue so that the owners can better understand how many customers are impacted in one place. |
|
@keithrob said:
Publishing tarballs is still very much a documented feature. So I think it's safe to add support for publishing .tgz files directly in the NPM task.
I don't see any NPM installer task. I see a Node tool installer task, and maybe that's loosely coupled with NPM, but it's not clear to me which version of Node.js to install in order to get a particular version of NPM. My attempt at a workaround for this is to use a PowerShell task to find the name of the file to publish (since the version changes for each release) and set that filename to a variable. Then my next release task is the NPM task with the 'custom' command set to |
|
So I eventually settled on the workaround of running |
|
Closing this as WF. In the upcoming quarter, we'll be moving away from the full-featured Artifacts-related tasks and recommending calling npm directly, which will give you the flexibility to call whatever command you wish, even if you're working against an authenticated feed. See the design here for more details. |





Hello,
I use VSTS to build and publish a NPM package.
I have a CI build which restores packages, executes the build scripts, runs
npm packand upload the .tgz file as an artifact. Then, I have a release definition which is responsible for deploying the package in VSTS Package Management, MyGet, or nmpjs public registry depending on the stability.The
npm packcommand creates a .tgz file with the package name and the version, so it is not possible to predict the final file name.However, the
argumentsinput of the NPM task does not support minimatch patterns.Plus, the
working folderinput is not necessary anymore in this mode (and should be let empty, or the task would fail with the error "TypeError: Cannot read property 'trim' of null").I think it would be great if we could choose either to publish a folder (and let the
working folderinput as is) or to publish a tarball (and add an input that supports minimatch for this purpose).As a temporary fix, I currently extract the tarball and then call the NPM publish task with the
working folderset.Thank you!
The text was updated successfully, but these errors were encountered: