Node package naming conventions

[tjaffri]

Every translator has a node package name in its package.json, e.g.

{
    "name": "opent2t-translator-wink-light-bulb",
    "version": "1.0.0",
    "description": "Wink Light Bulb",
    "homepage": "http://opentranslatorstothings.org",
    "dependencies": {},
    "devDependencies": {
        "async": "~1.5.2",
        "optimist": "0.6.1",
        "opent2t-onboarding-winkhub": "*"
    },
    "author": "",
    "license": "MIT"
}

We need to come up with a convention for these names, somehow aligning with the reverse-URI naming convention of the translator folders... This needs to get done before we publish these to NPM, but since it is not a directory structure change we can separate this from #43

[sanjaiganesh]

Also consider adding 'main and files' fields.

[jasongin]

I guess 'main' would refer to the translator .js file? Then would we reference that instead of relying on the filename being "thingTranslator.js" by convention?

I agree the files property will be necessary to get the right subset of directories/files into each translator's package. It's going to look really funny though with the package.json being in the wrong directory. Maybe the content of the files property should be dynamically generated by a build script?

[tjaffri]

The proposal we have is the following:

1. The npm package names will always have "opent2t-translator-" prefix
2. After the prefix, we will kebob-case the reverse-URI that is translator name, so e.g. "com.wink.lightbulb" becomes "opent2t-trasnslator-com-wink-lightbulb"

See here for package name rules: https://docs.npmjs.com/files/package.json

How does this sound?

[jasongin]

That sounds logical, but long. Since package names can be up to 214 chars, length shouldn't be a problem there.

I'm just a little concerned about total path lengths. NPM basically had to change how they organize and de-dup installed modules to avoid frequently exceeding MAX_PATH on Windows. Here we are proposing packages that have two levels of long-named subdirectories under a long-named package directory.

Unrelated to the length issue, did you consider using a "@openT2T" scope for translator packages? There are pros and cons to scoping packages, so I'm not sure if it would be the right thing to do for this project, but it's worth considering. Scopes are sometimes used by other large nodejs-based projects to give their "plugin" packages a separate namespace and to keep them from showing up in the general npm search. Reference https://docs.npmjs.com/misc/scope

[tjaffri]

Thanks, I'll follow up with a PR shortly.

Regarding long path names... that's a problem on Windows regardless of what we do here with many other packages. See here for some recommended workarounds/setup: https://github.com/Microsoft/nodejs-guidelines

Also, I think bash on Windows solves the max path problem but I am not sure. See here: http://www.hanselman.com/blog/DevelopersCanRunBashShellAndUsermodeUbuntuLinuxBinariesOnWindows10.aspx

Finally, yes we looked into scoping with @clca. Where we ended up for now is not to scope though it is clearly something we need to keep thinking about.

[jasongin]

I disagree that long names are "a problem regardless of what we do here". By choosing long package names and also having a directory structure within the packages with nested long names, we're making the issue harder to work around for our packages specifically.

As an example that is not even very extreme, the relative path to a translator JS file in one of our samples would be 179 characters:
node_modules/opent2t-translator-com-wink-thermostat-temperaturesensor/org.opent2t.sample.temperaturesensor.superpopular/com.wink.thermostat.temperaturesensor/js/thingTranslator.js

So it better not be installed to a project directory that is more than 80 chars deep.

[tjaffri]

What I meant was, OTHER node packages already have long path names so people are dealing with this problem already.

Clearly, we can do things here to make it worse or better... shorter names would clearly be better but then we have a namespacing issue.

It looks like folks are working on resolving this max path issue already and there are reasonable guidelines in the meantime to avoid running into this issue e.g. here: https://github.com/Microsoft/nodejs-guidelines

Finally, note that per the discussion above I am adding "main": "thingTranslator.js" to package.json but leaving out the files attribute for now. I will add the note to #51 about files since it seems reasonable to think about as part of that.