ipmjs
ipmjs copied to clipboard
ipmjs
Namespace all the things!
NPM broke the first rule of naming things by not namespacing package names.
Any replacement should not make the same mistake. Other package managers like Composer does this.
Use GitHub style namespaces, like someuser/somelibrary and someorganization/somepackage. Then the issue of name collision becomes much smaller (although potentially still possible).
I am a javaer and I'd like the java style package name, dot splitted full qualified name. How jsers think about it?
@xzer Personally I'm not much a fan. Might also cause problems for those libraries with dots in their names, as something.js is pretty popular with JavaScript libraries.
@AlexanderOMara you are right, simple name is more popular in js world, but I do not feel that simple name is a good solution for namespace/group name and at least java styled full qulified package name is better than simple single word name.
full qulified package name is better than simple single word name
True that @xzer
After thinking about it some more though, / separators more-closely match the ES6 module import pattern, so it probably makes sense to keep that (much like Java uses .). Otherwise, it might be feasible to allow going more levels deep.
@AlexanderOMara I just feel strange if we use / separator on namespace/group which is more usually without /.
How about we use dot as registered namespace name but we still import it follow the ES6 module's way?
I think using / is perfectly fine. I think would prefer that over anything else... Here is an idea on how to manage it:
Having packages in the node_modules folder, you could simply have one more depth for the namespace (node_modules/foo) then another folder for the package in that namespace (node_modules/foo/bar).
In context, this could be required/imported as:
var bar = require('foo/bar');
// or
import bar from 'foo/bar';
// alternative package:
import 'foo/bar';
node_modules could be structured to something similar to this:
.
└── node_modules
└── foo
├── bar
│ ├── index.js
│ ├── package.json
│ └── README.md
└── baz
├── index.js
├── package.json
└── README.md
@jamen in js import, / is of course more nature. but in the package.json(maybe ipm.json), the following code looks strange:
"devDependencies": {
"/org/grunt/grunt-webdriver": "0.4.8",
"/org/grunt/grunt-contrib-connect": "^0.9.0",
}
and the following looks more naturally:
"devDependencies": {
"org.grunt:grunt-webdriver:0.4.8",
"org.grunt:grunt-contrib-connect:^0.9.0",
}
I would just follow the convention all the way through, to remove confusion:
"dependencies": {
"foo/bar": "<version>"
}
Doesn't look too unnatural to me with the /org gone.
It conveys something very similar to what we have with package dependencies already.
@jamen it would be better if we allow more levels in the namespace, which cause some strange smell. assume your namespace as "foo/mama",so your style should be
"dependencies": {
"foo/mama/bar": "<version>"
}
so, what is the namespace and what is the module name?
then
"dependencies": {
"foo/mama:bar":"<version>"
}
or
"dependencies": {
"foo.mama:bar":"<version>"
}
or
"dependencies": [
"foo.mama:bar:<version>"
]
I like the final one.
@jamen it's different namespace. Slash is for module content, dots is for ownership of modules. But we have already socket.io. So we need something like : for use it between. Maybe we don't really need this dots just a : would be enough.
"devDependencies": {
"grunt:grunt-webdriver":"0.4.8",
"grunt:grunt-contrib-connect":"0.9.0",
}
That's look good for me.
Meteor packages use : as a delimiter — that doesn't confuse with directory paths or URLs like / does (unless your paths are always namespace/project anyway, like they are e.g. at GitHub.)
@xzer: Lets say hypothetically that this package manager did have multi-level namespaces... I think the file system should reflect that directly... It keeps it simple for the user and package manager itself:
node_modules
└── foo
├── bar
│ ├── index.js
│ ├── package.json
│ └── README.md
└── qux
└── rab
├── index.js
├── package.json
└── README.md
Could be imported/required as:
import rab from 'foo/qux/rab';
Each level of a namespace would just be a new folder containing more packages. Ultimately making the last item in the path the name of the module (i.e. foo/bar/qux, where qux would be the module).
But, at the end of the day, I don't really think multiple levels of namespaces are even necessary; although, a good discussion point. I'm open for convincing.
@KlonD90: Certainly quite the circumstance to run into... Perhaps the : in combination with the directory paths, to delimit a new path (or even a no-path name):
"dependencies": {
"kik:kik-app/libs/kik": "..."
}
Where the rule would be:
"[new_path]:<namespace_path>": "<version>"
The example above imported like so:
import kik from 'kik';
I think that is some pretty clear-cut syntax... Although, this is a rare scenario (I would imagine).
@jamen leveled namespace may be necessary for bigger company/organization which may has many independent but related subsidiaries.
And also how about kik.com and kik.de? who should have the right of the name of kik? Thus I think full qualified namespace is necessary.
That is good point.
The domain name (or something similar) could simply be used for the namespace: kik.com/kik, kik.de/kik, kik-app/kik, etc....
With my aliasing suggestion though, it doesn't really matter in the run: kik:kik.com/kik could be required as 'kik'.
"kik.com/kik": "..."
@jamen according to your solution, how about the real directory structure? leveled by "kik/com/kik" or flat as "kik.com/kik"?
I feel that if js community does not like dot separator, the flatted directory and dot allowed namespace may be good trade-off.
Same way I described above. Reflect in the file system:
node_modules
└── kik.com
└── kik
├── index.js
├── package.json
└── README.md