gitpkg publish v1.0.0-beta.2
[5/6] ⬆️ Uploading package...
× error Command failed with exit code 1: git commit -m gitpkg
On branch master
nothing to commit, working tree clean

It would be nice UX to add an install command with helpers for getting the latest gitpkg from a repo.

Also, thanks for the really handy module. Very useful for working around yarn/npm link issues

Thanks!

Just wanted to say that, since it helped me just now. :)
Feel free to close this when you are done smiling. ;)

Gitpkg is affected by the same bug reported here by me.
yarnpkg/yarn#6256

The root issue is that a git pull on the cached repo will not pull in the standalone tags (not reachable from the heads).

Related question on Stackoverflow:
https://stackoverflow.com/questions/16678072/fetching-all-tags-from-a-remote-with-git-pull/27911598

Bug

What is the current behavior?

yarn install fails to install subsequent Github URL packages with format
git+ssh://[email protected]:luwes/chameleon.git#cricket-v0.0.1-beta.3
git+ssh://[email protected]:luwes/chameleon.git#grasshopper-v0.0.1-beta.4

error Command failed.
Exit code: 128

What is the expected behavior?

yarn install installs the package

Node 10.6.0, Yarn 1.9.4, MacOS 10.13.3

As it stands, the versioned tags are great if the sub-package is relatively stable.
For things like internal framework modules which are used in many places, any
update to the lerna module requires modifications to all downstream usages.

It'd be good to have a ${pkgName}-latest tag, in addition to the versioned tag,
allowing in effect the same npm behaviour as @latest.

I'm trying to figure out how to be able to export a yarn workspace package in order to use within another internal project -- is this possible using gitpkg?

Anyone know the best way to approach this?

Thanks!

There should be an option to replace the already created tag with new changes instead of popping an error if same tag is requested.

Love this project! I've been experimenting with ways for https://github.com/aws-amplify/amplify-js/ to publish PR-previews (where each commit of a PR gets published artifacts so customers can validate PRs before merging), and I think this project could be perfect.

For a PR, I would like customize the following:

What's the best way could be handled? I'm happy to submit a PR so we could support some convention like 1.2.3-PR456-abc789 that would help us prune releases after they're respective PRs have been merged...

From google/wireit#273 (comment):

had a little dig, its an infinite loop!

await execLifecycleScript('publish', this.pkg, pkgPath);

It looks like setting "publish": "gitpkg publish" in package.json causes gitpkg to call itself recursively. It will throw an error if run naked (because the second tag push will fail), but causes the wireit script runner to hang.

@ramasilveyra do you recall why this line is there? Can we safely remove it (or make it optional, or detect and abort the recursive invocation)?

I forked the stitches project, made some changes, committed then tried gitpkg publish but it always hangs.

⠋ [5/6] ⬆️ Uploading package...

Any idea what causes this?

I've tried variations of the following:

yarn add recoilize@https://gitpkg.now.sh/open-source-labs/Recoilize/package?524ff2f9650e4a24e89ef00caa638b5148e9e966#.tgz

The #.tgz suffix is from yarnpkg/berry#2437 (comment)

But I can't get it to work.. any tips on installing w/ yarn and subdir + specific commit?

Hi.

I follow these steps:

1. run yarn global add gitpkg
2. run gitpkg publish

then I m stuck in the uploading packages stage, I checked the internet/VPN, all good.

package.json's private field can be used to denote packages that should not be published. It would be handy to use this field with gitpkg.

For instance, given:

packages
- core 
- extras
- demos (private: true)

running yarn workspaces run gitpkg publish --ignore-private would publish core and extras, but not demos.

We use gitpkg for publishing the internal packages as git tags, it works well for a project that uses yarn 1.

But on a project that uses Yarn 2 , getting an error while gitpkg tries to publish the tags. Can we support gitpkg when using yarn 2.

Stderr Status: gitpkg publish v1.0.0-beta.2

Stderr Status: lerna ERR! gitpkg publish stderr:

Stderr Status: - Processing...
events.js:353
      throw er; // Unhandled 'error' event
      ^

Error: ENOENT: no such file or directory, open '/projectyarn2/packages/package-xyz/package-xyz-v0.2.0.tgz'
Emitted 'error' event on ReadStream instance at:
    at internal/fs/streams.js:126:14
    at FSReqCallback.oncomplete (fs.js:180:23) {
  errno: -2,
  code: 'ENOENT',
  syscall: 'open',
  path: '/projectyarn2/packages/package-xyz/package-xyz-v0.2.0.tgz'
}

Hello.

When using gitpkg in repos with type "module" the configuration file is not loaded.
I logged the error thrown when trying to load the file below.
Is it possible to load .js/.cjs/.mjs?

Error [ERR_REQUIRE_ESM]: require() of ES Module /home/pdan/Work/PDan/vue-keyboard-trap/gitpkg.config.js from .config/yarn/global/node_modules/gitpkg/build/tasks/Task/read-config.js not supported.
gitpkg.config.js is treated as an ES module file as it is a .js file whose nearest parent package.json contains "type": "module" which declares all .js files in that package scope as ES modules.
Instead rename gitpkg.config.js to end in .cjs, change the requiring code to use dynamic import() which is available in all CommonJS modules, or change "type": "module" to "type": "commonjs" in vue-keyboard-trap/package.json to treat all .js files as CommonJS (using .mjs for all ES modules instead).

@ramasilveyra , Would you be open to committing the ./build directory to the repo?
Currently, npm installing https://github.com/sramam/gitpgkg (with my fixes for #9) doesn't
work.

I need to copy the build directory over manually from a local install.

Create Reference and Push need to be granted on /refs/tags/* in order for Gerrit to accept tags to orphaned commits from gitpkg.

This should be added to the README. (Leaving a note here as a stopgap until I get around to sending a PR.)

npm 5 and yarn can't that can handle git tags with @scope/name-package-1.0.0-gitpkg notation (last time tested).

That it's why I temporarily changed to a normalised version of scoped packages in #1

On a couple of projects some git deps were missing with npm v5, it appears that will be fixed with [email protected] https://twitter.com/maybekatz/status/880243586897293312

Hundreds of people are using gitpkg, and the code is very seldomly changed.

I think you can safely drop the beta and publish 1.0.0.

idea/discussion: just thinking aloud, comment whatever you think that could be wrong or could be improved.

Long git tags are awful:

{
  "dependencies": {
    "some-package": "github:ramasilveyra/private-registry#some-package-v1.0.0-gitpkg"
  }
}

maybe instead we could use the gitpkg: shortcut that infers the gitpkg registry from the field gitpkg.registry:

{
  "dependencies": {
    "some-package": "gitpkg:^1.0.0"
  },
  "gitpkg": {
    "registry": "[email protected]:ramasilveyra/private-registry.git"
  }
}

even we could have multiples gitpkg registries:

{
  "dependencies": {
    "some-package": "gitpkg:private:^1.0.0",
    "other-package": "gitpkg:public:^1.0.0"
  },
  "gitpkg": {
    "registries": {
      "private": "[email protected]:ramasilveyra/private-registry.git",
      "public": "[email protected]:ramasilveyra/public-registry.git"
    }
  }
}

For semver ranges if we can make the git tag name to be the same of the package even for scoped packages (see #4) the work on the npm client will be:

1. List git tags using ls-remote.
2. Select the correct version.
3. Fetch.

At the moment lerna doesn't link packages published as git deps (lerna bootstrap).

I still need to try yarn workspaces.

idea/discussion: just thinking aloud, comment whatever you think that could be wrong or could be improved.

Probably it will be possible to add the sha1 and sha512 on the commit description.

git commit -m "gitpkg" -m "{\"integrity\":{\"sha1\":\"<sha1 hash>\",\"sha512\":\"<sha512 hash>\"}}"

then the node package managers must validate against this.

Currently, gitpkg throws an error if the tag it wants to write already exists. Ideally, this would not error if the contents of the new tag and the old tag are the same.

Therefore, I propose an idempotent mode. Before pushing the tag, it would amend the commit time to 0 (1/1/1970). Then, you should be able to simply compare the SHA of the existing tag with the new one, and treat the command as a success if they match.

This would enable publish to be run indiscriminately across many packages, without worrying about which ones have fresh changes. It would also make it possible to easily detect which packages have changes since the last publication (since they would still throw the error.)

(I should investigate this a bit more, but wanted to write it down while it was in my head.)