On 17/04/14 19:02, Jamie Nguyen wrote:

The lodash-node module can be re-built by doing this:

$ lodash modularize compat -o compat $ lodash modularize underscore -o underscore $ lodash modularize modern -o modern

So you'll probably need to package lodash-cli first, remove lodash-node/{compat,modern,underscore}, and rebuild using the above commands.

That's my understanding anyway. I, err, could be wrong about all of the above..

I think you're about right, but it turns out there's an extra bit of fun here, namely that lodash-cli uses the closure-compiler npm, which is just a wrapper for the closure javascript minifier which has already been declared unpackagable...

Tom

On 17/04/14 19:02, Jamie Nguyen wrote:

On 16/04/14 16:35, Tom Hughes wrote:

...

I have an existing package that has a new version with a dependency on lodash-node so I was trying to package it but ran into the question of exactly what it is and how to deal with it...

We have lodash packaged already and as bast I can figure out lodash-node is the result of using lodash-cli to build node modules from lodash. Though I'm not sure what that means when lodash is already a node module?!?

In any case does that mean I should package lodash-cli first and then make the lodash-node package do that build step?

lodash-cli allows commands like this:

$ lodash compat $ lodash underscore $ lodash modern

The file created by each of the above contain a subset of lodash functionality tailored to whatever preset you've chosen.

lodash-node contains three subsets (compat, underscore, modern), but splits every single routine/function/method into a separate file. This allows individual methods to be required:

var isEqual = require('lodash-node/modern/objects/isEqual');

The lodash-node module can be re-built by doing this:

$ lodash modularize compat -o compat $ lodash modularize underscore -o underscore $ lodash modularize modern -o modern

So you'll probably need to package lodash-cli first, remove lodash-node/{compat,modern,underscore}, and rebuild using the above commands.

Further to all this, the package I had which required lodash-node has now switched to using half a dozen lodash.xxx modules instead.

We also have open review tickets for a large number of such modules, including three of the six that I now need.

Looking at it, it seems all those modules are built with lodash-cli by running:

lodash modularize modern exports="npm" -o ./npm/

which creates an entire directory full of 150+ lodash.xxx node modules.

Rather than packing each one individually, and in the spirit of packaging from source, should we in fact just have one SRPM which builds all the RPMs from source using lodash-cli?

Tom

On 01/08/14 21:36, T.C. Hollingsworth wrote:

On Wed, Jul 30, 2014 at 3:23 AM, Tom Hughes tom@compton.nu wrote:

...

Rather than packing each one individually, and in the spirit of packaging from source, should we in fact just have one SRPM which builds all the RPMs from source using lodash-cli?

Makes sense to me. :-)

So I've knocked up the attached patch which actually extends the existing nodejs-node-lodash spec file using some lua magic to generate the separate modules as well as the existing nodejs-lodash-node module.

The alternative is to create a separate srpm, but there isn't really a source to base it on other than the list of modules to build?

The package.json files it produces aren't quite the same as the published ones for the modules. I assume the differences are changes made by npm when publishing? Biggest issue is probably that the private flag is set, which means the auto-provide doesn't happen and I have to add it manually instead.

What do people think about this approach?

Tom

On Tue, Aug 5, 2014 at 11:35 AM, Tom Hughes tom@compton.nu wrote:

So I've knocked up the attached patch which actually extends the existing nodejs-node-lodash spec file using some lua magic to generate the separate modules as well as the existing nodejs-lodash-node module.

Yeah this belongs in the SRPM the source code comes from, so this is fine.

The alternative is to create a separate srpm, but there isn't really a source to base it on other than the list of modules to build?

The package.json files it produces aren't quite the same as the published ones for the modules. I assume the differences are changes made by npm when publishing?

I don't think npm changes anything when publishing. It does add a bunch of stuff to the JSON endpoints at https://registry.npmjs.org/ but AFAIK it leaves the package.json in the tarball alone.

But `npm init` and related commands add some extra fields intended for humans that aren't really necessary for stuff like this. So they can probably be ignored.

Biggest issue is probably that the private flag is set, which means the auto-provide doesn't happen and I have to add it manually instead.

I guess it would be more correct to strip the _private field from the JSON, but honestly I don't see how it matters very much...

What do people think about this approach?

Looks nice. I was having nightmares about texlive.spec but your lua magic here is much nicer and easier to see what's going on. Excellent work! Please commit.

Thanks, -T.C.