Suggested fixes to npm install

[kristianmandrup]

Change name entry in package.json file to a valid npm name

Try the tool validate-npm-package-name to validate it

"name": "@EastDesire/jscolor", -> change to "name": "@eastdesire/jscolor", - note: must be all lowercase

Add node module exports

Copy jscolor.js file to jscolor-node.js file and add module exports:

module.exports = window.jscolor // default export
exports.jscolor = window.jscolor // named export

Now point the main entry in package.json to jscolor-node.js

This will make it available for NodeJS projects in a compatible way (See https://stackoverflow.com/questions/30241729/how-do-i-perform-an-export-that-is-compatible-with-es5-and-es6). The compatibility is handled by a transpiler such as Babel for pure javascript or in TypeScript by the compiler itself.

ES6 module usage example (using import)

import * as JsColor from "@eastdesire/jscolor";
const element = document.createElement("x");
const picker = new JsColor(element);

Old style NodeJs usage example (using require)

const JsColor = require("@eastdesire/jscolor")
const element = document.createElement("x");
const picker = new JsColor(element);

Since jscolor is also exported as a name constant (via export.jscolor) you can also import as follows:

const { jscolor } = require("@eastdesire/jscolor")

Similarly for ES5 import

import { jscolor } from "@eastdesire/jscolor";

You can then export more named constants as needed to make it easier to use.

You might want to have a look at my TypeScript conversion for how to convert it to a proper Javascript class, if that is the direction you want to take it... Makes it much easier to extend and customise for the end user.

[EastDesire]

Thanks @kristianmandrup for your detailed suggestions.

Tried to publish 2.2.1 with lowercase username in package.json, but still getting "404 Not found" when running npm install on that package. I'll probably need to investigate a little further. The package name looks valid according to npm package naming rules.

As for adding the compatibility with Node.js projects, if this turns out to be desirable, I would rather make a "factory" enclosure in jscolor.js in a similar way jQuery does it, instead of making a copy of the source. But excuse my ignorance, why should we export the scope to Node.js in the first place?

jscolor is designed to run in a web browser and as such it requires window.document, for example, and Node.js doesn't have it. So I can't imagine any use case for accessing jscolor's API from Node.js.

I understand that packaging jscolor with npm comes handy for websites built using Node.js that want to install jscolor as a dependency, but the library itself will be run in client's browser, right? I'm I missing something?

[kristianmandrup]

Hi,

Since you haven't published the package to the npmjs repository, the package manager is unable to find it there, hence a 404 error.

To install it from your github repo, you need to tell npm this, f.ex using the following syntax (run in consumer project):

$ npm i -S github:@eastdesire/jscolor

To publish your package to npmjs, simply run:

$ npm publish

From within the jscolor project folder, after successful publish, you can then use:

$ npm i -S @eastdesire/jscolor

Which now retrieves the package from the npmjs global repo.

Note that i is shorthand for install and -S is shorhand for --save-dev (ie. save dependency reference to package.json)

Regarding browser vs node.js, it is quite common to distribute multiple versions of the same project for different consumers.
Alternatively use a common format as you point out, such as UMD (Universal Module Definition format).

I think you might well find rollup to be useful:
Install rollup globally

$ npm install --global rollup

Experiment by creating a IIFE (self executing wrapper, what you already have in fact)

rollup jscolor.js --file bundle.js --format iife

Create bundle in UMD format (for browser and NodeJS)

rollup jscolor.js --file bundle.js --format umd --name "JsColor"

Experiment with a simpler examples, such as a hello function or const x = 2 variable etc.

Why support both browser and NodeJS, well, with NodeJS it is common to simulate the browser (headless environment).
This is typically used when unit testing, doing acceptance tests etc. such as when using Jasmine, Jest, Mocha etc.

All modern web libraries are simply exported as an object, without polluting the global window object.
In modern web development we keep window clean (untouched). Then the consumer can opt to add the constant to window only if needed for whatever reason, not a decision enforced by library author.

Hope that answers your questions. Cheers!

[EastDesire]

What I actually needed to do was to remove GitHub's publishConfig configuration from package.json. I didn't know GitHub and npmjs are two separate registries.

Thanks for the explanation of the module definition formats. I'll put it on my TODO to add some universal wrapper there and hopefully will get to do it soon. At this point I'm happy that with your help we've published the first npmjs package. I had to use a scoped package name because unscoped jscolor seems to be already taken.

[brendon]

Great to see progress on this @EastDesire :)

As part of this packaging I was wondering if it would be possible to add an option to prevent jscolor from automatically mounting on data-jscolor elements? That way we can manually mount and unmount the picker on elements as required with something like https://stimulusjs.org

[EastDesire]

As part of this packaging I was wondering if it would be possible to add an option to prevent jscolor from automatically mounting on data-jscolor elements? That way we can manually mount and unmount the picker on elements as required with something like https://stimulusjs.org

Currently my idea is to check an optional data- attribute inside the <script> tag, something like:

<script src="jscolor.js" data-install="0"></script>

This should prevent the install() method from being called on DOMContentLoaded event.
I would check the attribute using document.currentScript.getAttribute() method (based on this stackoverflow post).

Do you think implementing this would do the trick for you, @brendon?

[brendon]

Thanks @EastDesire. I don't think that would work for me because I am including jscolor within a Webpack build so there is no script tag.

You could go something along the lines of this: https://stackoverflow.com/a/57543894/129798

So don't mount on data tags by default, but then perhaps check if the script was loaded from a script tag and auto-mount if that's the case. The start() method would be for if Webpack people wanted to kick off the normal behaviour of auto-mounting.

Hopefully that makes sense. :D

[brendon]

Sorry, looking into it further, you'd have to follow through with @kristianmandrup's recommendations of exporting a default JSColor object before this would work well. Currently you're relying on window which is ok, but doesn't allow for code encapsulation with tools like webpack.

[EastDesire]

@brendon, yes, it does make sense.

I currently can't devote much time looking into this completely new area for me. Honestly, I have never used jscolor in other environments than a standard HTML page (or planned for it) where document.window is always present. It seems surprising that jscolor works in module-oriented environments at all.

The idea from the beginning, although conservative and eccentric nowadays, was and is to have a single minimalistic JS file that can be edited as it is - no building process, no additional tools, just the text editor. That's why I'm hesitant to introduce any dependencies or CI, because the complexity of the app as a whole would start to grow in exponential manner.

I probably can't expect understanding in this matter, just wanted to explain the absence of tools that would make it easy to introduce AMD or similar module encapsulation.

I checked how jQuery handles this and if you think this simplified jquery-ish style encapsulation would work, I can add it in the devel branch so that you can test it:

(function(global, factory) {
	if (typeof module === 'object' && typeof module.exports === 'object') {
		module.exports = factory(global);
	} else {
		factory(global);
	}
})(
	typeof window !== 'undefined' ? window : this,
	function (window) {
		//
		// <jscolor code>
		//
		return jscolor;
	}
);

[brendon]

Thanks @EastDesire, I totally understand what you mean. I was skeptical about Webpack and it took a long time for me to understand why it helps. The above code looks good to me and I'd be happy to try it out. Here's my reasoning for using it in modular form:

I'm using https://stimulusjs.org of which the overall concept is that you attach data-controller attributes to nodes in the page and they automatically come to life through a connect() method on the stimulus controller. The connect method in this case would just call the jscolor code on the node associated with the data-controller. This is basically how jscolor already operates but StimulusJS also watches the document using a mutation observer and calls connect() whenever an element appears in the page with the correct data-controller attribute, so it can work with things like Turbolinks or Ajax that inserts new code into the page without having to remember to re-run thejscolor initialiser. StimulusJS can also remove things with a disconnect() method when the element is removed from the page.

Having JSColor available as an export from your module means I can use it without polluting the window namespace. It also means I can be explicit with my dependency on it. It's just a way of ensuring there are no side effects.

This should definitely not come at the detriment of the traditional way jscolor works though, and your solution above seems to make sure that's the case :)

[EastDesire]

Thanks @brendon. Please see the devel branch and let me know if it helped. I'm kinda guessing here to a certain extend, which isn't ideal, but we might get it working.

From what you said about stimulusjs.org, I think you might need to either call jscolor.install(element) for that particular element in its connect() method, or create a new JSColor picker instance there.

Also, I made jscolor.init() public, in case it's needed.

[brendon]

You're a legend @EastDesire :) That worked perfectly :)

[brendon]

The only small thing I noticed (which is probably not small in its solution!) is that there isn't a way to remove jscolor from an input. It's probably not a huge thing because in my case the only way the connect()method would be re-run is if the element is remove then re-added to the page, in which case it'd just be a standard input again. Probably nothing to bother about.

[EastDesire]

Good stuff @brendon, thanks for testing. It's now released in jscolor-2.4.0.

In terms of detaching the picker, I would like to introduce something like .uninstall() or .destroy(), but it's not the biggest priority at the moment. I'm happy that it can be at least worked around.

[brendon]

Thanks @EastDesire, I might have a go a that during the week and send you a PR if I have time :)

[brendon]

Just had a quick look through the code and my current thinking is:

• Keep a copy of the original element and hide/detach it when installing jscolor on an element.
• Uninstalling would just amount to removing the modified element and putting the original element back in its place.
• Transfer the value of the input back to the original element upon uninstall?
• What to do about the value, alpha and preview elements?
• Should we leave the picker element on the page?

No rush on this, just wanted to get your ideas on it :)