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

Publish on NPM #9

Open
mnn opened this issue Nov 29, 2016 · 7 comments
Open

Publish on NPM #9

mnn opened this issue Nov 29, 2016 · 7 comments

Comments

@mnn
Copy link
Owner

mnn commented Nov 29, 2016

Similar topic: typed-typings/npm-ramda#96

Investigate if it is even possible - this project uses two type files, mainly to circumvent limitations of TypeScript. I suspect it is not, because when I tried to use this repo by typings tool (it supports github as a source), it concatenated all files - essentially hiding all sanctuary types (like Maybe and others). 😞

@blakeembrey
Copy link

You need to refactor the definition to be in a different format when you're writing an external module. The common pattern is to use a namespace. See something like https://github.com/types/npm-passport-twitter/blob/master/lib/strategy.d.ts and https://github.com/typings/typings/blob/master/docs/examples.md#function--utility for more information.

@blakeembrey
Copy link

However, that comment was based on the fact I looked at your index.d.ts and misinterpreted. Instead, all you need to do is write it "flatter". Use something like:

export function pick (...): void;

export interface X {}

Instead of doing a namespace or interface directly as the export.

@mnn
Copy link
Owner Author

mnn commented Dec 1, 2016

I think I already tried that, but resulting JS did not work (because of a way require call was compiled). The problem is I need to default export an object of type SanctuaryModule (with create method) from main typings of sanctuary (index.d.ts, otherwise it will not generate working JS), but at a same time I need those other types which can't be in the index.d.ts, because one cannot have in one file a default export in a form of export=... and at a same time export something else (at least that was telling me TypeScript compiler).

Also I originally wanted to cover whole Sanctuary - default form from require and also a customized form from create. I could not make it working - either types were ok and JS was broken or the other way around. In the end I chose to only type path of create, because that is the way it will be used in production and for small/toy projects one have to use one cast to make it working. Since I don't think one can have a return type of a function to be a namespace, I used an interface (Sanctuary).

I am a TypeScript beginner, so if you think you are right please provide more details.

@blakeembrey
Copy link

and at a same time export something else (at least that was telling me TypeScript compiler).

Yes, you can - use a namespace and see this comment: #9 (comment).

I think I already tried that, but resulting JS did not work (because of a way require call was compiled).

How are you requiring it? From the docs, the exports were correct so I'd guess the import might be incorrect. From a definition point of view, it means exactly the same thing to do export = {} vs multiple exports at the top-level.

@mnn
Copy link
Owner Author

mnn commented Dec 2, 2016

When I have some time I might look at it and try again, but I am not very keen to toy with it too much (I have already rewritten whole typings from namespace to interface once, definitely won't do it again).

I have already spent in total over 3 work days (didn't know much about TS when I started), which I probably won't get paid for, just to get it working so I can use it at work (I am not planning on using it nor TS in my toy projects). In the current form it works - solution with a local package is good-enough for me and if this typings gets eventually pulled into sanctuary repo then I don't have to change a thing (typings repo has some requirements at least on formatting and tests), so this project at its current state is not very high on my personal todo list.

If you or anyone else would like to try to change it I would gladly accept PRs.

@mnn
Copy link
Owner Author

mnn commented Dec 7, 2016

Note to myself: Try typesRoot TS compiler option. It might be considerably easier this way - users would simply add this project's package path to their tsconfig.json and the package itself could be a regular npm package maintained by me.

@KiaraGrouwstra
Copy link
Contributor

KiaraGrouwstra commented Dec 21, 2016

maybe @types would be an option here as well :)

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