Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature Request] Expose modules without lib/es6 prefix #32

Closed
CYBAI opened this issue Aug 24, 2020 · 5 comments
Closed

[Feature Request] Expose modules without lib/es6 prefix #32

CYBAI opened this issue Aug 24, 2020 · 5 comments

Comments

@CYBAI
Copy link
Contributor

CYBAI commented Aug 24, 2020

🚀 Feature request

Current Behavior

As a parser-ts user, I will need to import modules like parser-ts/lib/Parser or parser-ts/es6/Parser.

Desired Behavior

Ideally, it would be great to just import the module directly without prefix like parser-ts/Parser that fp-ts already shipped in 2.8.0.

Suggested Solution

Maybe we can follow what fp-ts has done in gcanti/fp-ts#1241 to fix this.

Who does this impact? Who is this for?

parser-ts users

Describe alternatives you've considered

Additional context

Your environment

Software Version(s)
fp-ts 2.8.0
parser-ts 0.6.3
TypeScript 3.9.2

(I also filed another similar issue for fp-ts-contrib at gcanti/fp-ts-contrib#67)

@CYBAI
Copy link
Contributor Author

CYBAI commented Aug 24, 2020

I'm wondering maybe #29 already fixed the tree shaking part and the only thing needs to be done for this issue is to build the targets directly instead of being under lib or es6 👀? (IIUC, we will still keep the lib and es6 target for compatibility like fp-ts I guess?)

@IMax153
Copy link
Collaborator

IMax153 commented Aug 27, 2020

Hey @CYBAI, sorry for not getting back to you sooner on this.

The issues surrounding tree-shakability were handled with #29 when pipeable was removed from the library and the "mega" type class instances were split into their respective individual type class instances.

The issue you are raising I think has more to do with the import ergonomics of the library. I would be happy to work on implementation of direct imports for parser-ts, but I think (similar to our discussion in #31) the issue will come up as to how this should be handled across the ecosystem.

  • Does every single library that wants to implement direct imports have to copy over the scripts to do so?
  • Or can we create a utility library (similar to import-path-rewrite) that can be used selectively by packages that wish to implement this feature?

@gcanti - sorry to ping you once again, but would you mind weighing in on the above? If a utility library is desired, I am happy to work on implementation. Otherwise, I will just port over the scripts from fp-ts to allow for direct imports of the parser-ts modules.

@gcanti
Copy link
Owner

gcanti commented Aug 28, 2020

Or can we create a utility library (similar to import-path-rewrite) that can be used selectively by packages that wish to implement this feature?

Yeah, that's something I would like to work on as soon as I find some time. In the meanwhile we could do what @osdiab did here

@gcanti
Copy link
Owner

gcanti commented Sep 11, 2020

Released https://github.com/gcanti/parser-ts/releases/tag/0.6.9

@CYBAI
Copy link
Contributor Author

CYBAI commented Sep 11, 2020

@gcanti thank you so much!!!!!!!!!!!!!!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants