eorroe
Publish on npm
Just stumbled on this library and it's amazing, even more so it's gzipped size! my workflow complety revolves around npm and I think I'd be great if NodeList gets published as an npm package.
This sounds good, but I haven't created any modules in npm ever, I only use npm for backend, but if you could do it that'd be pretty awesome, and I'll mention it in the README
It's super easy. I think it would be better if you can do it yourself since you as the author should decide on the license and when a new release happens.
https://docs.npmjs.com/getting-started/publishing-npm-packages https://gist.github.com/coolaj86/1318304
Honestly not sure if there are going to be new releases, or versioning, since this library does automatic upgrading because it uses the browser that its running on as a dependency. Therefore I don't define my own methods.
If I start making my own methods you got yourself another jQuery sort of.
Only crucial methods like get(), set(), and the item() method, also you have the asArray property (uses a getter instead of a method i.e toArray())
I can help publish. Let me know. Bower is another one that would be nice to pull from.
Sure thing, but that'd be after I make the npm module? (Sorry I haven't created very big applications, that are complex and where I use modules yet, so I don't really use those things, npm, gulp, grunt, bower, etc)
@PeterDaveHello That's is really awesome, but I'm wondering, why would there be versioning? There won't be anything to break.
I mention in the repo, that this library depends on the browser that it runs on, meaning I won't be breaking anything, if a browser vendor removes the method addEventListener then you can't do:
$$('.child').addEventListener('click', function(evt) {...});
But as we all know addEventListener won't be removed because its Highly used.
So the only deprecation that devs will need to worry about are the ones that browser vendors deprecate (which as I said in the repo, are the ones that are rarely used)
Still can version it to make sure what version we are using, unless you are sure you will never edit the code again, or the versioning will be useful, and latest is not a good method for the cache control, and we don't even know what new features are not in my currently using file, if unfortunately, there is a breaking change, it'll be also hard to confirm that, we don't use it on cdn, even though you don't want it to be hosted on cdn, versioning is still good on my point.
even though you don't want it to be hosted on cdn
I do want it hosted on cdn (that's why I said awesome)
Now question: Could it be versioned on the cdn? Where let's say v1 of NodeList.js on cdnjs
cdnjs keeps its own version, instead of myself
I believe that's what you mean by?:
Still can version it to make sure what version we are using
Could it be versioned on the cdn? Where let's say v1 of NodeList.js on cdnjs cdnjs keeps its own version, instead of myself
Yes, but I wanna make it consistent with official repo, it'll be better if we host it.
make it consistent with official repo
What do you mean? as in I never update the repo?
it'll be better if we host it
Just the current version, or the whole project? (really confused, please elaborate)
What do you mean? as in I never update the repo?
I meant not let cdnjs keeps its own version, that's why we need versioning, v0.0.1 is always v0.0.1, no matter it's on official GitHub repo or on cdnjs :smile:
Just the current version, or the whole project? (really confused, please elaborate)
We only host the files that browser will need to use, not the whole project, let's take foundation-essential as an example.
Crap I really don't wanna version though, as I feel as if when theirs a version number behind it, an update is expected.
You said only way is if I will never touch the code again
But I can't guarantee that, I can't think of something that the library really needs added, but they may be something someone comes up with, but majority of it will be things that they can simply implement on their own that is not needed. (So your answer would probably be that's why you version it :laughing: , but yea really don't want to version it)
There will be a time where I don't need to update it anymore (meaning I won't even touch it, when the time comes I'll let you know) just waiting for some feedback, so far nobody who has starred it gave any input as to what to add, I guess they love it just like it works now :smile:
I agree that having this available via npm / bower / cdn would be huge. I would use this all the time.
I don't think people would expect or demand updates (hopefully that's not how this comes across), so much as they'd be happy to have an extremely useful library available through typical channels, rather than requiring special steps (going to this page and downloading the library separately, adding it to a "vendor" dir that might not otherwise need to be there if all of the other dependencies come from npm).
If you aren't planning to do versioned releases, you could make it 0.1.0 and leave it at that, though it's still flexible enough that if you do get worthwhile feedback you can bump it down the road. Changing the spec itself would be cool but it's becoming more and more common for projects to incorporate small modules like this (along with transpilers) to fill in what the browser APIs lack. It would be a shame not to make this available in a usable way, especially after you already did the work of writing the code and documenting it really well.
Thanks!
Also wrap it in UMD/commonJS or else having it on npm would have little sense.
+1, many people use npm and browserify so you definitely should publish it on npm. Versioning should not be a question, if you publish something you must version it, so we can follow the changes between releases. You don't have to update it, we can fork and send pull requests if you don't want to develop the code.
It is not that hard, all you need is 1.) install node.js 2.) create a package.json file:
{
"name": "nodelist.js",
"version": "0.1.0",
"description": "NodeList implementation/library - Use the Native DOM APIs as easily as jQuery",
"keywords": [
"dom"
],
"license": "MIT",
"author": "Edwin Reynoso",
"repository": {
"type": "git",
"url": "https://github.com/eorroe/NodeList.js"
},
"bugs": {
"url": "https://github.com/eorroe/NodeList.js/issues"
},
"main": "NodeList.js"
}
3.) Modify this part of the code:
window.$$ = function NodeListJS() {
return new NodeList( arguments );
}
to be
module.exports = function NodeListJS() {
return new NodeList( arguments );
}
Ofc. you can create another file for commonjs, e.g. common.js but in that case you have to use "main": "common.js" in your package.json file.
4.) Add a .npmignore file and ignore every file you don't want to publish.
5.) Open a terminal, go to the repo directory and run npm publish.
That's all.
After that we can install the lib using npm with npm install nodelist.js and use it as var $$ = require("nodelist.js").
Publishing on bower is very similar.
You don't have to wait for the lib getting stable. Just publish it with 0.1.0 version and increase the revision version number by bugfixes and the minor version number if you added some new features. After it became stable you can increase the major version number to 1.0.0. HTH, good luck!
@inf3rno I'm aware of how to do it, just 1 question if I change the NodeList.js file ending to module.exports = how will I be able to load this via a <script> tag?
And wow man 1 thing I really hate is creating accounts for things I don't use or plan on using, so this is gonna suck.
@bfred-it I'm not sure what your talking about. I don't use these things so you're going to have to help me out here.
@gwicksted You said you can help out with bower, is there anything you need me to do?
@eorroe We use http://browserify.org/ to do that. As I already wrote, you don't have to change the original file, create a new file with commonjs and ignore the original file by publishing the repo to npm. What account?
@inf3rno How do I
create a new file with commonjs
I don't know how to use commonjs or what you want me to do with it
and an npm account, I don't have to sign up to publish a module?
Can also use a wrapper to support multiple module types. Modified example UMD wrapper
(function (root, factory) {
if (typeof define === 'function' && define.amd) {
// AMD. Register as an anonymous module.
define([], factory);
} else if (typeof module === 'object' && module.exports) {
// Node. Does not work with strict CommonJS, but
// only CommonJS-like environments that support module.exports,
// like Node.
module.exports = factory();
} else {
// Browser globals (root is window)
root.returnExports = factory();
}
}(this, function () {
// replace the {} with your object
return {};
}));
@gwicksted I prefer not, a seperate file would be nice, but I'm still confused on all this
@eorroe All you need is doing the changes described in 3.) and the lib will be commonjs compatible.
@inf3rno but then I won't be able to just add a <script> tag in my html file and load it, because module.exports is not something the browser understands
@eorroe That's why you need a separate file for the commonjs compatible code. If you want to use it with script tag, then you use the original file, and if you want to use the lib with browserify, then you install the commonjs compatible file from npm. What's the problem?
@eorroe Hmm I checked the code, there is window.NodeList and window.Symbol by many places. It might need more modification to make it commonjs compatbile. I'll fork it tomorrow and send the modifications in a pull request.