TypeScript support?

[mindplay-dk]

Does Pear (and Bare) have any support for TypeScript?

Does your runtime include type declarations?

(There is no mention of TypeScript anywhere in the documentation, as far as I can tell.)

[davidmarkclements]

the policy is that Pear Applications do not prevent the usage of transformations, and moving forward we're looking at supporting transformations via configuration. It's also possible right now to just use webpack to create a dist folder and then run/stage/seed that folder.

As for declarations, this (both Pear and Bare) is a JavaScript runtime, the requirements of any languages or language extensions that compile to a target language should be decoupled from the language-proper - so declarations are a matter for the community/authors of that language/language extension. For example, the node project does not maintain node type declarations, the DefinitelyTyped community does.

[mindplay-dk]

I don't think I would trust third-party types - for an API of this size and complexity, in a codebase without types, typically only the maintainers can really be trusted to know what's what.

I understand Node gets by this way, but their type declarations have hundreds of contributors.

If you won't entertain first-party TypeScript support, perhaps you might consider JSDoc annotations? These provide good IDE support as well, for example via the TypeScript Language Service in VS Code.

You have a unique and interesting project here, but coding blind just really isn't my cup of tea. 😅

[davidmarkclements]

I understand where you're coming from and people have different approaches/tooling/etc when it comes to writing code - we're still stabilising so declarations/annotations is overhead I want to avoid for as long as possible but at the same time I think we should enable IDE support where possible also.

The Pear API itself is very small, and Bare even more so, keeping small cores and having functionality in libraries (e.g. bare-fs, hyperdrive) means decoupled iteration, which means faster overall iteration so this is actually more of a Pear Ecosystem discussion but I agree with you on the point of IDE integration so I think we should do something about that (maybe annotations, maybe something else)

[davidmarkclements]

@mindplay-dk in todays Pear update (v0.4444.pqbzjhqyonxprx8hghxexnmctw75mr91ewqw5dxe1zmntfyaddqy) we have support for https://github.com/holepunchto/pear-interface

From the changelog:

• IDE / Types - pear-interface dev-dep autosyncing to current platform Pear API for synchronized IDE autocomplete support

If you install pear-interface as a development dependency into a pear project, the pear-interface will be synced with the pear-interface that matches the current version of Pear. This way autocomplete is always up to date.

Templates have also been updated to include pear-interface as dev dep and import it via jsdoc comment (pear init desktop / pear init terminal)

We'll be adding the Bare global to pear-interface at some point also but it will be evolving to d.ts types, which is why I'm reopening this issue.

So for now, it's a dev dependency only. In future it can be used for production types, which is a much bigger commitment, I'll want to mature the API a little more first and we need to think about opportunities for Pear to solve the type-syncing on a production level as well.

To get IDE autocomplete in your existing Pear project:

npm install --save-dev pear-interface

In the entry point file add:

/** @typedef {import('pear-interface')} */

[davidmarkclements]

regarding the direction change, I had a long chat with @kasperisager about it and it just makes sense to use d.ts in terms of tooling and supporting the TS ecosystem etc. It's nicely self contained in pear-interface now, we can start with jsdoc comments to indicate we're not yet taking on supporting TS, but now we have a path to potentially solving the type mismatching problem for production too I think it's just a good idea to eventually support d.ts types for Pear & Bare