Open marvinhagemeister opened 8 years ago
+1
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)
If there is versioning, we can distribute this lib over cdnjs :smile:
@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)
@PeterDaveHello therefore could it distrubute the latest of NodeList.js?
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)
Yeah, no problem, it's up to you.
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.
@gwicksted ayy man what I'm trying to say is that I don't use anything like build tools, transpilers, requirejs/commonjs, etc. I make simple applications, and just use plain old <script>
when I get into bigger applications that I need to use module systems I'll look into those things. So right now I don't use any of that.
Which is why I'm asking if you guys could contribute and do that, instead of myself, because I really don't want to download or learn how to use any of that right now.
and @inf3rno alright thanks
@eorroe Working on it: https://github.com/inf3rno/NodeList.js , but I ended up writing a gulp task file loader for it. :D Currently the minifier task is complete. I have to test the commonjs compatibility and add a gulp task to convert the current file into a commonjs compatible file. I think I'll finish it tomorrow. After that you can pull in, build with gulp and publish on npm.
I suggest you to write some selenium or karma tests to verify the code. (I'd prefer karma if I were you.)
@inf3rno Like I said never used gulp before, so not sure what to do, and I also made a change on the library today. concat()
was doing some expensive stuff that it didn't have to, so now its more performant and faster. So how would I upgrade from your change?
@eorroe We will discuss it as soon as I finished. As long as it is only a single file it won't matter, I'll copy the new file probably autoformat the code with webstorm, and that's all. Building with gulp and publishing on npm are just 2 command line commands. I assume you can copy-paste them.
Check this please: https://github.com/inf3rno/NodeList.js/blob/master/src/nodelist.js is it okay to have this kind of reformatted code, or you want to keep the original code formatting style? Do you use a code autoformatting tool?
Why do you pass undefined as param?
@inf3rno That's how I actually write code, but I did some spacing out to make it easier on the eyes for devs, because the minified version should be used in production anyways.
Also by the way your file size is bigger than mine for some reason, I don't think its because of my change, because my change actually made it bigger, so I'm really confused on that.
I pass undefined
because some old browsers may still allow undefined
to be set. So if someone were to set undefined
my library won't break, even though I don't pass a whole set of other stuff, from the window scope (I probably should, or just not pass anything at all).
Oh I know why its because you're using spaces instead of tabs
@eorroe Ofc., but you should not worry about file sizes that's why we use the minifier...
Never heard of setting undefined. Probably it does not matter anyways, I mean you use ES5 features like Object.getOwnPropertyNames
and Object.defineProperty
, which most probably won't work with these older browsers you refer.
@inf3rno I don't use Object.getOwnPropertyNames
, and jQuery passes undefined
Yea just saw that, forgot about that, thought you meant for getting the properties of the div
(my bad)
@eorroe I fail to see why passing undefined helps. If sy overrides it, you will pass the wrong value. I'd rather use a secure source like void 0
to compare or check with typeof
. Does not really matter, your choice. Good night!
@eorroe It is ready for pull request. I think I have to fork again, since I moved the js file to the src lib and reformatted its code. Let me know when you commit next time. I'll fork after that, make the changes and send a pull request.
After that you have to pull the changes to your dev machine, install node.js, open a terminal (or git bash on windows), go to the repo root, run npm install
, npm run build
and npm publish
.
The lib name will be "nodelist.js" on npm, so it can be installed with npm install nodelist.js
. If you want to change the name, let me know. The "nodelist" name is already taken. (I am not sure about the ".js" part, as far as I know npm names can have dots, but for example bower names cannot, so with this name it won't be consistent if somebody adds bower later.) The dist contains the release files, I assume you want to create github pages for the project and add the release files there. One thing is sure, you should not source control them. You could use github built in release solution too, but I don't know how to do that. You have to add version tags, but I am not sure how to attach the release files from the dist after that.
I wrote some jasmine tests. Not much, maybe 30% coverage. You can run the tests with karma start
. Auto-watch is on, so by changing the src/nodelist.js or the test files the tests will run automatically in firefox. An alternative approach to download and copy the current jasmine to the vendor/jasmine and open the jasmine-runner.html in different browsers. The npm run test
runs karma too, but is for travis only. On windows it did not work with opera and msie properly (the launchers are buggy), but maybe it works by travis on linux. If not you should remove the opera and ie browsers from the tasks/test/karma.js, otherwise the travis test will be red. You should register the lib on travis after you accepted the pull request. I am not sure about the travis.yml. In theory it should work, but we won't know before running it on travis.
(Currently the build script replaces the window.$$
with module.exports
, so if somebody wants to use it with a nodejs dom lib then it won't work, because it uses window.Symbol
and other stuff. Maybe I'll add support for that next time.)
I have found a bug by testing msie. The remove() method did not work. I am not sure why, you should test it. I got the error here. It claimed that the remove() is not defined. Other browsers were okay. Another feature that the node order in the selection is not always what we would expect (I had to use sort in my tests because of that). It might be an issue by your firstChild
related examples.
@inf3rno I just commited, I already have node.js.
As for the lib name we could just omit the .
and name it NodeListJS
which should work for both npm and bower right?
I don't see a dist
folder in your repo
I assume you want to create github pages for the project and add the release files there
Nope I won't be making a github page for this
Biggest thing I'm confused about is, I've only submitted pull reqeust to other repos I've contributed to on github, not sure how to merge them correctly, I feel like something may go wrong (The docs on pull request are a bit confusing).
Now since we agreed on a different file, how do I link that different file to the npm module, looking at what you did above:
"repository": {
"type": "git",
"url": "https://github.com/eorroe/NodeList.js"
},
It's linking to the whole repo, how would it know which file to look at?
As for tests, not sure what you want me to do really? Create more tests?
remove()
was not defined because some browsers may not support that method, remember I don't provide any DOM methods.
Another feature that the node order in the selection is not always what we would expect (I had to use sort in my tests because of that). It might be an issue by your firstChild related examples.
Not sure what you're talking about
And for the window
in my source code, are you sure this module will work correctly, not trying to create one if its not going to work correctly?
@eorroe As far as I know package names are case insensitive. The dist folder isn't there, because the built files are not under version control. This is the standard procedure. You have to run the build and publish the minified code somewhere else. That's why I asked about the github pages. The npm code can be published after build directly from the repo with npm publish.
I meant that there is an order in the DOM tree and the $$(selector)
does not select items in that order. E.g. I add 3 divs to the body and call $$("div"). The result will be in random order, that's why I needed to use DOM. The lib is okay. If you are confused about pull requests, it is better to copy the relevant parts of the code to your repo remove the minified file and move the other file to the src folder. You should rename it to nodelist.js instead of NodeList.js. Linux filesystems are case sensitive while Windows filesystems aren't, so it is better to use always lowercase file names.
You should copy the travis part from the readme file as well. After that register the lib on travis.
After that run the npm test and debug your code or override the tests I wrote. If it is okay, then run the 3 commands I already mentioned: npm install, npm run build and npm publish. That's all. I don't have more time for this currently, I hope you can solve it alone.
Hi guys, @eorroe and @inf3rno Is this library on npm.com
yet? How can I get a module version?
@izackhub Still no package.json file, so I think not. You can publish it if you want, I don't code much client side nowadays.
Nope, this project is pretty much dead to me honestly 😏, I have no idea how many people actually use this in production, so no motivation to refactor, and actually do anything with it. (I would love to refactor to FP since that's what I'm writing these days and would improve code readability by a lot)
Same as @inf3rno I don't do any frontend work anymore either (NodeJS now) and would prefer using a framework.
@izackhub curious to know how you found this and what you're working on? (Reply here #11)
I did spend spend a couple hours yesterday trying to rewrite it to typescript. but nature of free javascript makes it hard approach it in a direct way. I'm having some issues with the parameter types and the double functions. if you have had any typescript experience I'd like to to take a quick look if you don't mind @eorroe
@izackhub I have lots of TypeScript experience -- you could start by writing the .d.ts
for this library but certain JS idioms can make this task harder than rewriting it in TS itself if you haven't done a lot of TS before. Since most of this is browser-native, one of the best resources for types would be the lib.d.ts
that comes with TypeScript.
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.