8 ms·
Show HN: JSON.is
- fizzbatter 10y agoThis is cool! I would have loved something like this for Yaml recently as i learned Rust's Cargo.yaml
- steveklabnik 10y agoCargo uses TOML, not YAML. (But yeah, this is really cool, and that would be really cool!)
- fizzbatter 10y agoAh yes, forgot about that. You are correct
- caub 10y agoI thought it would introspect each dependency too
- zackbloom 10y agoThat's a good idea! You can find the repo here: https://github.com/eagerio/json.is https://github.com/eagerio/json.is, you should open an issue.
- jmhnilbog 10y agoI feel like an idiot, but I can't tell what this is and the "About" page isn't helping me.
- zackbloom 10y agoIt's an editor for those JSON file formats which shows contextual help as you edit the files, similar to an IDE. It works by parsing the javascript and figuring out where your cursor is relative to the syntax of that particular format.
- jmhnilbog 10y agoI'm not seeing any of that.
- Twirrim 10y agoLikewise. The landing page gave me no clue. I just now went back and clicked on one of those documents, assuming that I'd get some kind of documentation about the format. Turns out it opened a live document editor. I certainly wouldn't have predicted that from the line "Open-source documentation for common JSON formats."
- swsieber 10y agoIt's documenting the structure of json files used in large projects. On of the three, for example, is documenting the package.json file used by npm. It gives an inline editor to view what one looks like.
- dimgl 10y agoThat contrast is abysmal. Please fix the contrast on the code samples.
- zackbloom 10y agoThe buttons aren't actually meant to be read. If you click them, you get to the actual code page which has a much better contrast ratio: http://install.json.is/ http://install.json.is/
- deleted 10y ago[deleted]
- leppr 10y agoNice presentation, and it would be even better if it could be integrated as a plugin for text editors (vim/emacs/...). Waiting for a good webpack.config.js one :)
- zackbloom 10y agoGo for it ;) https://github.com/EagerIO/JSON.is/tree/master/coffee/formats https://github.com/EagerIO/JSON.is/tree/master/coffee/format...
- Bromlife 10y agoWebpack config files are not JSON. They are full JavaScript.
- leppr 10y agoI haven't used webpack enough to be certain but AFAIK, like grunt, the config part is basically just JSON. Sure you can build your object dynamically, but it isn't something like gulp where you use functions to configure your project. In the end you're just exporting one big JSON-serializable object.
- SamBam 10y agoIs http://package.json.is/ http://package.json.is/ really better documentation for what package.json should look like than than regular-ol' documentation, https://docs.npmjs.com/files/package.json https://docs.npmjs.com/files/package.json? It seems that this format, while a clever idea, is going to have a lot of problems in describing more complex json documents, which may have optional arguments, arguments that are mutually-exclusive, etc etc. For example, in the package.json example alone, there are several properties that can be either a string or an object, but it would be hard to expose that in this system. But maybe this isn't supposed to be documentation, in which case I'm just confused about the purpose of this. Edit: If more information about the available properties were available at each level (i.e. from the top-level, here are all the possible props; from the "contributors" prop, here are the different possibilities) and this could be used to document one's own project-specific JSON, this could be very cool. But the best would be if it had a way to integrate with a proper schema validator.
- aeorgnoieang 10y agoYes, because it could be available while looking at your actual config file (JSON document), and showing you info specific to the element you're looking at, instead of on a separate page and requiring searching for a relevant element. Why would this be any harder to describe complex JSON documents? Optional arguments don't need to be described if they're not in your specific file – not by something like this anyways. That's what the regular documentation is for, and this could easily link to it too. Mutually exclusive arguments can easily be linked-to, or, rather, if your file contains one of those arguments then the contextual info can link to any other mutually exclusive arguments. Why couldn't the context info state that valid values include either a string or an object (of some type and that type linked to in the context info)? I'm confused about your confusion! It seems like this is a really handy way to show documentation specific to a selected portion of a JSON object for a given format.
- SamBam 10y agoOP described the tool as this: "It's an editor for those JSON file formats which shows contextual help as you edit the files." Is that what it's supposed to be? Because what I was saying was lacking was any contextual help that tells you what you could add, vs what's already there. If I were shown http://package.json.is http://package.json.is as "contextual help" to help me author my package.json file, I would have no idea that I could add "author" or "contributor" fields. This only gives documentation for the stuff that is already there. You could add every property to the original document, but that fails if you have mutually-exclusive properties, because the original document would not be valid. You could try to add every possible property to the top-level comment, but then the top-level comment needs to be practically as long as the original documentation. Documentation that is incomplete, and doesn't seem to have a reasonable way to make it complete, doesn't seem useful to me -- and in many ways seems worse than not having it, because the incompletion means I would never even realize I was missing useful documentation. I'd have to have the real documentation open on another page anyway, to make sure I'm not missing stuff. But again, maybe I'm missing the use-case.
- killercup 10y agoNice, but too bad this is not in JSON Schema (it's a custom bunch of html strings in functions). I would love a more complete JSON Schema for package.json (with custom stuff like browserify or babel config) as VSCode is able to autocomplete JSON files from that.
- alexatkeplar 10y agoExactly - why invent some artisanal Turing-complete thing involving regular expressions and tied to a single proglang when you could achieve the same in a fully declarative, language-agnostic fashion by adding the "description" field into JSON Schemas for the same source documents?
- wwwigham 10y agoI'm pretty sure you'd just need to contribute an updated definition to http://schemastore.org/json/ http://schemastore.org/json/ then.
- sotojuan 10y agoWould be helpful to add JSON API.
- andyfleming 10y agoIs install.json something new or is it used by an existing platform/toolset?
- zackbloom 10y agoIt's used to build Eager Apps (and can be used by anything which needs to install a library in a non-technical-person friendly way): https://eager.io/developer/docs/install-json https://eager.io/developer/docs/install-json
- andyfleming 10y agoOh, nice! I sent you an invite on LinkedIn. Shoot me a message and let's connect!
- yvesmh 10y agoI wish something like this was available when I was writing my resume using fresh schema (https://github.com/fresh-standard/FRESCA https://github.com/fresh-standard/FRESCA) for HackMyResume (http://please.hackmyresume.com/ http://please.hackmyresume.com/)
- brilee 10y agoThere's this structured data format called XML, and typically you put a XML schema definition at the top (example: <xs:schema xmlns:xs="http://maven.apache.org/xsd/settings-1.0.0.xsd"> http://maven.apache.org/xsd/settings-1.0.0.xsd"> for a Maven config file). XML code editors then fetch the XML schema declaration, which contains information like what fields are expected, whether those fields are repeatable, whether they are required, and so on. Java library using XML as configuration will typically have published an XSD. Fun fact: XML schema declarations are themselves XML documents, and there exists an XSD describing allowable XSDs. https://www.w3.org/2001/XMLSchema.xsd https://www.w3.org/2001/XMLSchema.xsd
- throwaway284534 10y agoI'm confident that everyone knows about XML and that you're a worse troll than I am. Nobody contests XML's capability. It was unpleasant to write and read.
- nine_k 10y agoJson forbids comments. It makes writing it much less pleasurable than it might be.
- coderholic 10y agoFor good reason though. From Crockford: > I removed comments from JSON because I saw people were using them to hold parsing directives, a practice which would have destroyed interoperability. I know that the lack of comments makes some people sad, but it shouldn't. via https://plus.google.com/+DouglasCrockfordEsq/posts/RK8qyGVaGSr https://plus.google.com/+DouglasCrockfordEsq/posts/RK8qyGVaG...
- taeric 10y agoI'd say "for reasons" not necessarily "good" ones. In particular, I think the jury is still out. The hacks that people have done to get comments into npm files are really quite illuminating.
- erichurkman 10y agoBreaks for me using Safari: TypeError: null is not an object (evaluating 'style.overflow') — works on Chrome.
- paulddraper 10y ago> Since package.json.is is primarily a code editor, it’s not really well-suited for small screens. > Please check us out on a larger screen. :) > Email yourself a reminder WTF? You might not know this, but my phone is equipped with advanced pinch-and-zoom technology you may not have seen before.
- voiper1 10y agoThat's very nice document-panel on the side! If we could get that in sublime or vscode, that would be pretty cool!
- deleted 10y ago[deleted]