search

funkia / list

🐆 An immutable list with unmatched performance and a comprehensive functional API.
MIT License
1.65k stars 51 forks source link

Replace custom make-proxies script with cherry-pick tool #52

Closed Andarist closed 6 years ago

Andarist commented 6 years ago

Please verify directories which are created, but I've looked at them (& developed my package by npm linking and using it on ur package 😉) and they should be fine.

paldepind commented 6 years ago

The cherry-pick library/tool looks really nice! 😄 I think it's both a helpful tool and a nice way to document/establish the technique.

The only thing I'm concerned about is how it determines how to create the proxies? Currently, in List, there is a one to one correspondence between the files in /src (and thus /dist) and the proxies that should be created. But, what if the main index.ts gets split into several files that then gets reexported by an index.ts file? Will cherry-pick then create proxies for the internal files? How should we handle that?

Andarist commented 6 years ago

Well, at the moment I assume that everything directly in the inputDir (this defaults to src) needs a proxy directory. This ofc might create some extra ones, but in general it shouldn't do any harm. I don't check nested directories at the moment, so it's possible to "hide" modules in some internal dir or whatever.

This is MVP of the tool, didn't want to overload it with options just yet - just aiming for most popular use case. I'd like to handle glob patterns, so you'd be able to control generated directories more easily, but that would force me to handle nested directories right from the starts and I'm not sure if there is any demand for this.

paldepind commented 6 years ago

One approach would be for the script to accept a list of names for the proxies one would want to create:

cherry-pick --proxies foo bar baz

To me, that seems simpler than a glob?

In any case, I agree that generating a few extra proxies doesn't do any harm. Thanks a lot for the PR. I think creating a tool for this was a great idea 😄

paldepind commented 6 years ago

I love the emoticons from the script 😸

Andarist commented 6 years ago

List of modules would certainly be easier than a glob, but i.e. in case of libraries with bigger API surface (i.e. ramda) it would be troublesome. So it seems to me that if such use cases exist and I'd like to support them it's better to support them in a single, more powerful, way (glob).

Thanks for the feedback ❤️ I was surprised that cherry-pick name was available, when I've taken it emojis were obvious 😄

paldepind commented 6 years ago

List of modules would certainly be easier than a glob, but i.e. in case of libraries with bigger API surface (i.e. ramda) it would be troublesome. So it seems to me that if such use cases exist and I'd like to support them it's better to support them in a single, more powerful, way (glob).

That is a good point. I agree.