Publish on npm about nodelist.js HOT 49 OPEN

+1

from nodelist.js.

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

from nodelist.js.

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

from nodelist.js.

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())

from nodelist.js.

I can help publish. Let me know. Bower is another one that would be nice to pull from.

from nodelist.js.

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)

from nodelist.js.

If there is versioning, we can distribute this lib over cdnjs 😄

from nodelist.js.

@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)

from nodelist.js.

@PeterDaveHello therefore could it distrubute the latest of NodeList.js?

from 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.

from nodelist.js.

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

from nodelist.js.

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.

from nodelist.js.

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)

from nodelist.js.

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 😄

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.

from nodelist.js.

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 😆 , but yea really don't want to version it)

from nodelist.js.

Yeah, no problem, it's up to you.

from nodelist.js.

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 😄

from nodelist.js.

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!

from nodelist.js.

Also wrap it in UMD/commonJS or else having it on npm would have little sense.

from nodelist.js.

+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!

from nodelist.js.

@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?

from nodelist.js.

@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?

from nodelist.js.

@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?

from nodelist.js.

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 {};
}));

from nodelist.js.

@gwicksted I prefer not, a seperate file would be nice, but I'm still confused on all this

from nodelist.js.

@eorroe All you need is doing the changes described in 3.) and the lib will be commonjs compatible.

from nodelist.js.

@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

from nodelist.js.

@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?

from nodelist.js.

@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.

from nodelist.js.

You could also use grunt and execute the grunt-umd plugin

from nodelist.js.

@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

from nodelist.js.

@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.)

from nodelist.js.

@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?

from nodelist.js.

@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?

from nodelist.js.

@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).

from nodelist.js.

Oh I know why its because you're using spaces instead of tabs

from nodelist.js.

@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.

from nodelist.js.

@Inf3rno I don't use Object.getOwnPropertyNames, and jQuery passes undefined

from nodelist.js.

@eorroe https://github.com/eorroe/NodeList.js/blob/master/NodeList.js#L177

from nodelist.js.

Yea just saw that, forgot about that, thought you meant for getting the properties of the div (my bad)

from nodelist.js.

@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!

from nodelist.js.

@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.

from nodelist.js.

@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?

from nodelist.js.

@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.

from nodelist.js.

Hi guys, @eorroe and @Inf3rno Is this library on npm.com yet? How can I get a module version?

from nodelist.js.

@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.

from nodelist.js.

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)

from nodelist.js.

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

from nodelist.js.

@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.

from nodelist.js.