Is there an easy way to install only a function or two?

[justin-calleja]

I'd like to use one of the functions in a project - but I don't want to depend on everything in this package.

For e.g. I'd like to use apply. Is my only option to copy-paste the relevant code? Are there / will there be "micro-lib" implementations of the functions in this package?

btw, I am aware that some build tools can detect unused code and remove it from the built bundle.

[justin-calleja]

I've went ahead and extracted 2 of the functions I'm primarily interested in atm:

https://www.npmjs.com/package/@justinc/fpo-apply
https://www.npmjs.com/package/@justinc/fpo-curry-multiple

Thanks for the awesome library!

(they're MIT licensed and give attribution. If there's any other attribution I need to give in the repo / npm package - let me know and I'll add it).

[getify]

As discussed in #1, the plan is to eventually have some sort of option for either importing only certain methods (ES6 modules style -- with tree shaking taking care of removing unused stuff) or customizing a build (lodash style).

But I'm just curious, given that the whole library (unminified) gzips to under 5k, which is pretty small, what's the particular motivation of wanting to split out specific methods?

[getify]

BTW, by dumping those into standalone files, you actually expose them differently than FPO does... because FPO actually curryMultiple's each API method, including (ironically) curryMultiple(..) itself.

IOW, this works with FPO:

FPO.apply( {props: ["x","y"]} )
   ( {fn: foo} );

But with your exposing of apply(..), it won't. It'll have to be used as:

apply( {props: ["x","y"], fn: foo} );

That could be a gotcha for people reading code, to expect it to work the same as the methods from FPO. You might either change them to both be curried (you can do it manually), or at least note in the documentation that this difference exists, to prevent confusion.

[justin-calleja]

Well, maybe it's just my lack of understanding with how these things are optimised via bundlers like Webpack.

I'm using these 2 functions in another "micro" lib, itself exporting a function (and I wanted to write this function "normally" and then give it the properties I get from apply and curryMultiple).

I don't want packages depending on this package to pull in all of FPO, when that lib could itself be pulling in all of Ramda - etc…

ah... I just saw your latest comment. Fair enough - I think I'll go with documenting it - or another small package which exports both of them. Basically, I'm just interested in the property of making my own functions "FPO" style (or "named argument" style). (in "rare" cases where the number of args gets a bit too much).

[justin-calleja]

Also... even if "tree shaking" detects what I'm using from Ramda / FPO and pulls in only that code - I'm inclined to still prefer a solution which pulls in only the code I'm using on my dev machine too... it's just a personal preference - but yes, I'd agree that the "real" issue would be serving it to client browsers.

[getify]

Makes sense. I'd recommend bundling these two together then. :)

[justin-calleja]

I've added a note and published so it shows up in npm (README).

Thanks again Kyle! Named args can be pretty handy :)

btw, I think I'll leave them as 2 separate packages. I don't mind that their behaviour is non-curried as long as I get to make certain other selected functions "multi-curried" + "named args" using them.

(I expect that this won't be a "big deal" if anybody else wants to do the same thing).

[justin-calleja]

@getify , perhaps I can make a better case now that I've published what I had in mind... nothing special, just a single function I was using in a project which I thought might be re-usable and didn't want to have to think about re-implementing it:

https://github.com/justin-calleja/to-validation

That's depending on:

https://www.npmjs.com/package/@justinc/fpo-apply
https://www.npmjs.com/package/@justinc/fpo-curry-multiple

For a single function, it might make more sense why I do not want anything other than what it needs (not the whole FPO... nor the Webpack runtime for e.g.)

I've just familiarised myself a bit with rollup and am trying to cut out my @justinc packages and depend on FPO directly, I would then like rollup to tree shake any unused functions from FPO in the resulting bundle (which I intend to have in the UMD format, as well as a package.module field pointing to my source.. which is using ES6 modules).

I'm not sure if there's a way to do this from rollup but the plugin config below is not working (it's bundling all of FPO):

  plugins: [
    nodeResolve({
      jsnext: false,
      main: false,
      module: true
    }),
    commonjs({
      namedExports: {
        'fpo': [ 'curryMultiple', 'apply' ]
      }
    })
  ]

It seems like tree shaking won't work unless the module I'm importing (FPO) is written using ES6 modules.

Re this issue #1
I don't think you need to write each function in a separate file. It might be possible to keep your code written the way it is (UMD), and transpile it to ES6 module exports (I've never done it this way, only the other way round, e.g. ES6 to CJS). Once you have that, you should be able to just add a package.module field on your built file.

[getify]

Sorry I never responded here. Your suggestion of using ES6 modules as a transpilation target rather than a source is spot-on with my way of thinking. I am hoping to create a tool that can do just that, but I haven't built it yet.

[justin-calleja]

Hey @getify no problem. I forgot (exactly) what this was about to be honest. I was just playing around with an idea.

Thanks for all the great JS resources you put out there! :)