This should check to see if the version of the package you are trying to publish is already published and stop you.

CI for this repo is running at Node 0.10 😱 We should upgrade.

cc @mapbox/assembly-line

We are no longer using this project at Mapbox. We should archive this project or move it to the cutting room floor: https://github.com/cutting-room-floor.

cc/ @mapbox/platform @mapbox/security

Right now if npm-internal publish fails, it just prints

[package name]
Uploading Package to S3

and finishes without indicating failure.

I can look into this sometime... wonder if npm-internal should switch to straight env vars as well?

Since npm-internal relies on local git tags to name packages, you can end up with invalid versions unless you've recently git fetch'd to be in sync with the remote. For example:

My local repository has git tags up to version 0.12.0 but the remote version is all the way up to 0.18.2. When I npm-publish --dev the package name includes 0.12.0 even though the code is is synced with the most recent commit on the project.

It'd be great to either:

1. add git fetch to the default command, to make sure the user is in sync with the remote
2. add a warning message of some sorts, ensuring people are up to date with the remote

cc @GretaCB

Ran into problems around first run.

stream.js:81
      throw er; // Unhandled stream error in pipe.
            ^
Error: ENOENT, open 'usage.md'

This should be fixable by putting a __dirname in front of the path to usage.md here:

https://github.com/mick/npm-internal/blob/master/index.js#L19

Will PR over the weekend.

im trying trying to deploy a branch of dynamosm-operator that uses a dev pacakge of dynamosm, but hitting a Expected version 0.6.0 of dynamosm but found 0.12.1 error from mbx deploy. this is because --dev first gets it's gitsha from git describe --tags rather than just reading package.json: https://github.com/mapbox/npm-internal/blob/master/index.js#L48

i think the ideal behavior would be to always always read the package.json version and never tags (assuming it's unlikely that if you're publishing a dev pkg that you've incremented the tag).

i can do a quickie PR that just removes https://github.com/mapbox/npm-internal/blob/master/index.js#L48 ?

@freenerd @karenzshea

nvm

Rather than use tags or v0.0.0, use version found in package.json and append a -dev and gitsha

cc @mick @freenerd @emilymcafee

When npm-internal prints the URL after publishing, it should print an https URL rather than an http URL.

Hey @mick - two questions:

1. What's the best way to check what packages are available?
2. What's the best way to install packages? Is the only way to do this to save the URL npm-internal gives me and use that as the source?

When I run npm-internal publish --dev, it generates a url with my package location, but when I run npm-internal show it says No packages found, even though I'm able to access the package from the url provided.

dev publish: mapbox-unpacker-reporting-v1.0.0-734db30d2d31fee2ad4bc9e89c2351f0812b0e7d
mapbox-unpacker-reporting-1.0.0.tgz
Uploading Package to S3
package url: https://mapbox-npm.s3.amazonaws.com/package/mapbox-unpacker-reporting-v1.0.0-734db30d2d31fee2ad4bc9e89c2351f0812b0e7d-2e2d331a7d96915f83407f8991ebcdeb29c09c76.tgz
~/mapbox/unpacker-reporting[master]$ npm-internal show
No package found```

having a folder with .idea files prevents the publish function from working normally.

It returns:

Aborting: the package contains the following files not tracked in Git.
This is often a mistake. Use -f/--force to override this check.
  .idea/.name
  ...

If I move those files outside of my project folder everything works fine.

Seems like there an issue with non_git_files_present at
https://github.com/mapbox/npm-internal/blob/master/index.js#L87

npm install
npm ERR! fetch failed https://FOOBAR.s3.amazonaws.com/package/foobar-1.0.0-0f239c76cfa7foose7b55a495ba10.tgz
npm WARN retry will retry, error on last attempt: Error: fetch failed with status code 400

Worked after switching to v4, but took me a while to figure it out. Printing a message would be helpful.

nvm ls
       v0.10.43
       v0.12.14
->       v4.4.4
         v5.0.0

@mapsam and I ran into the same issue:
If your local repo does not have the latest remote tags, npm-internal publish --dev will attempt to publish the latest local version instead of the actual latest remote version. This is a confusing bug to troubleshoot.

In order to avoid having to troubleshoot this altogether, what if git fetch was run automatically when running npm-internal publish --dev?

Perhaps relevant to #19 ?

cc @karenzshea @freenerd

I tried running npm-internal publish --dev but got the following output:

dev publish: <my-package>-

<my-package>-6.2.1 already exists.
Please either increment the version number in package.json to remove the conflict and try again.
Or for a dev package use --dev

My understanding of --dev is that it should be appending a hash to the version number to avoid duplicate version problems. Is there a bug or am I misunderstanding?

Dollarstore idea to try? Provide redirect HTML files at N.x.x and N.N.x locations on the s3 bucket and update them with new releases.

$ npm-internal publish mypackage
- v1.0.5 published
- v1.0.x redirect updated to v1.0.5
- v1.x redirect updated to v1.0.5

cc @emilymcafee

GitHub tarball links make it easy to reference unreleased commits and branches in dependencies from another project's package.json file, but these links don't work for private projects.

Can npm-internal help publish devbuilds? Instead of refusing to publish npm-internal could publish a package named based on the output of git describe.

The output looks like v0.8.0-161-g8685bfe, where v0.8.0 is the latest tag, 161 is the number of commits since the tag, and g8685bfe is the partial SHA of the current commit. Running git describe with the tag checked out will simply return v0.8.0.

/cc @GretaCB @lbud

Required Elements

If any elements in the below list are not checked, this repo will fail standards compliance.

• Not running node 4 or below
• Has at least some test coverage?
• Has a README?
• Has no hard-coded critical secrets like API keys?

Rubric

• 1 pt Is in Version Control/Github ✅ (free points)
• 1-2 pt node version:
  • 2 pt Best: running node 8+ 🏅
  • 1 pt Questionable: node 6
  • 0 pt Not ok: running node4 or below ⛔️
• 1 pt No hard-coded config parameters?
• 1 pt No special branches that need to be deployed?
• N/A 1 pt All production stacks on latest master?
• 1 pt No hard-coded secrets like API keys?
• 1 pt No secrets in CloudFormation templates that don’t use [secure]?
• 1 pt CI enabled for repo?
• 1 pt Not running Circle CI version 1? (Point awarded if using Travis)
• 1 pt nyc integrated to show test coverage summary?
• 1-3 pt test coverage percentage from nyc?
  • 3 pt High coverage: > 90%
  • 2 pt Moderate coverage: between 75 and 90% total coverage
  • 1 pt 0 - 74% test coverage
• 1-2 pt evidence of bug fixes/edge cases being tested?
  • 2 pt Strong evidence/several instances noted
  • 1 pt Some evidence
• 1 pt no flags to enable different functionality in non-test environments?
• 1 pt Has README?
• 1-2 pt README explains purpose of a project and how it works to some detail?
  • 2 pt High (but appropriate) amount of detail about the project
  • 1 pt Some detail about the project documented, could be more extensive
• 1 pt README contains dev install instructions?
• 1 pt README contains CI badges, as appropriate?
• 1-2 pt Code seems self-documenting: file/module names, function names, variables? No redundant comments to explain naming conventions?
  • 2 pt Strongly self-documented code, little to no improvements needed
  • 1 pt Some evidence of self-documenting code
• 1 pt No extraneous permissions in IAM roles?
• 1 pt Stack has alarms for AWS resources used routed to PagerDuty? (CPU utilization, Lambda failures, etc.)
• 1 pt Stack has other appropriate alarms routed to PagerDuty? (Point awarded if no other alarms needed)
• 1 pt Alarms documented?
• master branch protected?
  • 1 pt PRs can only be merged if tests are passing?
  • 1 pt PRs must be approved before merging?
• 2 pt BONUS: was this repo covered in a deep dive at some point?

Total possible: 30 points (+2 bonus)
Grading scale:

Repo grade: 14 -- Scaled Grade 2

Although the grade could be higher: a lot of the rubric related to alarms, monitoring does not necessarily apply to libraries like this.

cc @mapbox/assembly-line

running npm-internal publish for a scoped module currently fails:

Error: ENOENT: no such file or directory, lstat '@org/package-name-1.0.0.tgz'

It appears npm pack creates a package tgz with the following name: org-package-name-1.0.0.tgz instead of creating a new folder called @org/. When s3.putObject comes along it looks for a packaged module within the @org/ folder but it doesn't exist.

It seems like the quickest fix would be to update the expected path for s3 to put, rather than requiring npm to create the actual @org folder.

cc @rclark

Yesterday I used the latest version of npm-internal (d73792e) to publish a package.

I ran into a weird issue where my package would install but could not be required in another module.

Working with @ianshward, we noticed that the index.js file was missing from the published package, causing it to install successfully but fail on require(). This happened despite index.js being in the repo - it had been neither deleted nor modified as part of my commits for that package.

I was able to get around the issue by using 5cb9c23 and re-publishing the package. The index.js file appeared in my package again. Now the package can be require successfully.

/cc @mapbox/devops

yarn not created index file so after that my simulator not able to find root file please solve this issue.

Any thoughts on expanding this, or me expanding this to include support for Google Cloud Storage or other locations for npm modules?

Cheers