Investigate using @n-api npm tag

[gabrielschulhof]

What is the maintainers' workflow for publishing?

What is the workflow for depending on vs. depending on the mainstream V8 version? (package.json)

[aruneshchandra]

It will be also useful to understand what might be the workflow of older Node.js versions which will get N-API later on.

[jasongin]

npm tags documentation

And don't confuse tags with npm scopes, which also use a @ prefix but are something entirely different.

[gabrielschulhof]

@jasongin I tried to build iotivity-node against node-api and I found that the headers are a bit behind - for example, napi_get_last_error_info() doesn't have the env parameter. I kinda need that before I can publish. Is that coming soon?

[jasongin]

@gabrielschulhof The node-api repo was updated for that change last week. Make sure you have the latest. If there are any remaining issues, please open issues under that repo.

[gabrielschulhof]

@jasongin I think you may have grabbed an older version of the header/source code when you added support for pre-N-API Node.js: https://github.com/nodejs/node-api/blob/master/src/node_api.h#L97

[gabrielschulhof]

I'm trying to build on Node.js version 4.0.0 BTW.

[jasongin]

Oh, yes that copy of the code hasn't been updated in a while. I was waiting for things to settle before I updated it again. You can manually copy the node_api* source files from the nodejs/node master branch; there aren't supposed to be any differences.

[gabrielschulhof]

I know, but I want to eventually publish to npm.

[gabrielschulhof]

But OK, I'll make a fork and depend on that for now.

…

On Fri, Apr 14, 2017 at 10:51 PM, Schulhof, Gabriel ***@***.***> wrote: I know, but I want to eventually publish to npm.

[gabrielschulhof]

I have just published iotivity-node version 1.2.0-3 to the "n-api" tag. When you type npm install iotivity-node, you get 1.2.0-2, which is the latest published version. However, if you type npm install iotivity-node@n-api, you get 1.2.0-3.

So, I think the way tags work is like this:

latest	n-api
...	...
1.2.1-1?
	1.2.1-0?
↓past	↑future
	1.2.0-3
1.2.0-2
1.2.0-1
1.2.0-0
...	...

So, in terms of semver, I think packages can take advantage of the dash-field. npm accepts it just fine. So, for example, version on the latest tag can take the traditional form of major.minor.patch, whereas packages on the n-api tag can take the same form, except with a -0 attached.

[gabrielschulhof]

I guess in terms of developers' workflow, how they maintain their bindings (branch/prepublish script/etc.) is up to them, but basically, to publish is as simple as

npm login
npm publish

for V8, and

npm login
npm publish --tag n-api

for N-API.

[gabrielschulhof]

It looks like only one version can be tagged in a certain way. This means that when a later version is tagged as either @latest or @n-api the versions before it are all folded into a single sequence of versions. So, npm tags are not like git branches. There is only one branch with tags along the way which each tag moving forward as a new version is published under that tag. Below is the npm view output of a dummy package I published.

{ name: 'npm-test-p4ck4g3',
  'dist-tags': { latest: '1.0.1', sometag: '1.0.1-sometag' },
  versions: [ '1.0.0-sometag', '1.0.0', '1.0.1-sometag', '1.0.1' ],
  maintainers: [ 'gabrielschulhof <gabriel.schulhof@intel.com>' ],
  time: 
   { modified: '2017-04-27T19:25:28.770Z',
     created: '2017-04-27T19:23:29.321Z',
     '1.0.0': '2017-04-27T19:23:29.321Z',
     '1.0.0-sometag': '2017-04-27T19:24:52.541Z',
     '1.0.1': '2017-04-27T19:25:11.315Z',
     '1.0.1-sometag': '2017-04-27T19:25:28.770Z' },
  license: 'ISC',
  readmeFilename: '',
  version: '1.0.1',
  description: '',
  main: 'index.js',
  scripts: { test: 'echo "Error: no test specified" && exit 1' },
  author: '',
  dist: 
   { shasum: 'a61f936d507bafd1ae5608c95625bd74a7cf06a0',
     tarball: 'https://registry.npmjs.org/npm-test-p4ck4g3/-/npm-test-p4ck4g3-1.0.1.tgz' },
  directories: {} }

[gabrielschulhof]

Dependents can write

  ...
  "dependencies": {
    "npm-test-p4ck4g3": "sometag"
  }
  ...

and they will receive the latest version published under the tag sometag, however, they can specify no version ranges such that only those that were once tagged sometag will be examined.