Skip to content
This repository has been archived by the owner on Jul 30, 2020. It is now read-only.

npm publish #3

Closed
hrajchert opened this issue Nov 5, 2018 · 10 comments
Closed

npm publish #3

hrajchert opened this issue Nov 5, 2018 · 10 comments

Comments

@hrajchert
Copy link

Hi!, I'm trying to type mdx, which leads me to type unified, which leads me to type this. I've tried installing your types but I don't see them in npm, are you planning to add them soon? or to type other parts of the ecosystem?

Thanks!

@hrajchert
Copy link
Author

Here is my initial try to type the ecosystem :) https://github.com/hrajchert/unified-typings-test

@wooorm
Copy link
Member

wooorm commented Nov 10, 2018

@hrajchert That’s awesome!

@wooorm
Copy link
Member

wooorm commented Nov 10, 2018

@hrajchert I think we’re almost ready to do just that. But I’m not entirely sure how to write the readme. I mean, something like this, but I’m not sure how to document the usage of typings best? Any thoughts?

@hrajchert
Copy link
Author

Well, typings should be invisible most of the times, you should just install @types/unist and be done with it... I've normally havent seen readme on types pages :P

@cherue
Copy link

cherue commented Nov 13, 2018

The unist types should be put on DefinitelyTyped which makes them available to install with npm install @types/unist. The process for that is just updating https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/unist and then putting a note in the unist readme that types are available with npm install @types/unist.

Putting definitions in a separate repo is non standard and a possible source of confusion. I suggest putting types for the ecosystem npm modules inside them because Typescript can handle those automatically. This also makes updating them very easy because DefinitelyTyped is kinda annoying to keep updated and more for community provided definitions (unist is a special case). The way that would work is to manually write a .d.ts definition file and point to it in package.json with the types key. This definition file would need to be updated whenever the API changes. Unless...

How do you feel about porting everything to Typescript? I know I was hesistant to embrace Typescript because I felt like it would be a lot of work for little gain and that it would get in the way. But after getting used to it I found that it makes life much easier with all the insights it provides. What made me finally switch/give it a shot was finding out about ts-node for running .ts files without first compiling them. Anyways I'd be happy to port a bunch of the unist-utils I wanna use and would end up writing definitions for. And if you're into it I'll help with the rest, too. And if not I'll PR some definitions.

Also I just wanna say that this project/ecosystem is great, wish I found it sooner! 🎉

@ChristianMurphy
Copy link
Member

There is also a TS Definition discussion going on at https://spectrum.chat/unified/vfile/fix-vfile-type-definitions~5f1a8b89-b6d3-49a7-8158-0dd03595f2dc

@hrajchert
Copy link
Author

I think the problem of having the types as a .d.ts in the package alongside the code is as @wooorm sugested in this issue, not ideal. unifiedjs/unified#33

The problem is that mantaining both code and types can be annoying. The ideal is to have it written in TypeScript, and I think its heading that direction (look at the unified collective announcement).

@wooorm has asked me to publish the types under DefinitelyTyped and I think this Thursday I'll have some time to do it.

@wooorm
Copy link
Member

wooorm commented Nov 27, 2018

I’m 👍 on having types. I’m 👍 on writing micromark in typescript. I’m 👎 on rewriting everything in typescript.

Maybe I’m old but I’ve seen CoffeeScript. I love JS, it’s great. Most projects under unified are old. TypeScript is new and maybe it’ll fade. Maybe types are coming to JS, we’ll see, but I don’t want to rewrite 200+ projects in a new language every X years. Longevity is important.

We can have typings with everything: that’s good. They’re a bit hard to maintain next to JS, but if y’all are up for that, sure!


Aside, for @zcei’s comment on spectrum, I still don’t think types should go into spec projects (unist, mdast, nlcst, hast). These are just a readme, and should be agnostic of language. I’m up for having types somewhere, and maybe Go/Rust/TS/Flow could all be combined, maybe they need separate repo’s. But they’re not the spec itself.
How I feel about that is kinda like how Sindre feels about CLIs and APIs in the same repo: they’re different concepts.

@hrajchert
Copy link
Author

I've updated the current definitions of @types/unist to match the ones in this repository... hopefully it gets merged soon so I can publish the rest of the types.

I agree with @wooorm that we shouldn't rewrite just for the sake of rewriting. If it works it works. Not sure what is your opinion for future packages, if you saw a benefit on using typescript on micromark or what.

My first OSS project was (and still is) written in CoffeeScript :P. I understand the fear of writing something that may fade away. I'm more optimistic about TypeScript than CoffeScript for a couple of reasons... maybe I'll make a post about the comparison :)

@hrajchert
Copy link
Author

The package is published under @types/unist and it's merged with the latest changes. Future work will include removing the definitions from this repo (so we don't have duplicate code) and using it instead for documentation purposes, indicating how we can program in the unified ecosystem with TypeScript.

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

No branches or pull requests

4 participants