Publish NPM Module

[mbleigh]

If you'd like to see wider adoption of this, I'd very strongly recommend you figure out a way to make the bundle compiler as simple as:

npm install -g lovefield
lovefield my_schema.yml

Having to manually install dependencies and the location of the closure compiler just isn't how things are done in the wider web world. Additionally, there should be easy hooks for others to build ecosystem plugins for things like Grunt, Gulp, etc.

Not trying to sound grumpy, but I think Lovefield is a really cool project and I'd like to see it get all the adoption it can get! :ghost: :smile_cat:

[arthurhsu]

Thanks for the opinion. We are evaluating different options for Lovefield workflow and have not reached a decision yet. One option we are considering about is using gradle. What do you think about that?

[mbleigh]

So there are two "users" to consider:

1. The end user who just wants to create an app that uses Lovefield
2. The contributing user who wants to contribute to the project itself

Gradle (which I hadn't heard of, so can't tell you one way or another about its quality) seems to be a solution that affects the second group (people who want to build the project from scratch and/or contribute to it). For the first group, no matter how you do the actual building, the end result should be released as a package on NPM (since it's a Node.js command-line tool).

You could use e.g. the closurecompiler module from NPM as a dependency to automatically install that for users, and then refactor the command to run as a standard NPM executable (see this article for a primer).

Does that all make sense? I'm trying to be helpful, having an npm package will make people much, much more likely to pick up and try out Lovefield.

[arthurhsu]

It's easy to do npm command-line. What I worried about is that users can mistake that Lovefield can be used in node.js, which is not true. Anyway, the suggestion is very helpful and thanks a bunch for it! I'm looking into it and evaluating different approaches. Can't give exact ETA but hopefully soon.

[7sempra]

The standard Node way of doing this is to provide two APIs:

1. A command-line tool (intended to be installed with the -g flag) that users can call manually from the command-line or integrate with whatever build system they happen to be using. (this is what mbleigh is suggesting)
2. A JS API (in this case, probably a single function build()), which can be consumed by JS-based build systems such as Grunt. Users would install Lovefield locally, their build scripts would require it as a normal Node module, and then call the API from there.

1 is the most important, #2 is nice to have but not critical. If you want to use gradle, I would hide it from the end-user (have an opaque lovefield CLI).

[dominictarr]

There are a lot of client side packages on npm! By all means, support another package manager too, but npm is the largest javascript package manager, and if you want adoption, it would be a very good idea.

If you don't publish it to npm, someone else will, I can guarantee you that.

[arthurhsu]

The plan to address the flow for "just use Lovefield, no plan to hack on it":

Commit bb5ec8d362ba7abe224e3b489992f828c4a78c12 removes the dependency of Closure compiler/library for most people except Closure library users. The users shall be able to just run SPAC to generate JS files, and include these files and the dist/lovefield{.min}.js in their web page to use it.

NPM package for SPAC will come in later.

[arthurhsu]

NPM package for SPAC is implemented. It's not published to NPM listing due to its high dependency of Lovefield source code (in short, each lovefield-spac must be bundled with lovefield.min.js for the same revision). As a result, we'll still ask user to git clone Lovefield and install the NPM package from within spac/.

[freshp86]

FYI, Lovefield is now available through NPM, see https://www.npmjs.com/package/lovefield.