-
Notifications
You must be signed in to change notification settings - Fork 29.6k
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
Load JSON-LD in the same way as JSON #3502
Conversation
If I understand correctly, this could be done in an npm module? Perhaps that would be a better place for this? |
@Fishrock123 Well, loading |
I mean a module that sets |
Sure, but again: it seems strange to be able to load some JSON without a module, and to require a module for other JSON. Don't get me wrong: I think the JSON-LD made the wrong decision to require a distinct MIME type and file extension. I think such approaches should be discouraged. But it's there, it's standard, it seems to be increasingly common, and it seems to me like it ought to be processed identically to JSON so that us developers don't have to worry about superficial differences. |
Has a conclusion been reached on this? Is it something that should be brought before the TC? |
I don't think we should encourage writing modules that use internal undocumented functionality. |
Hmm... I tend to agree that we shouldn't be requiring modules to use undocumented bits to enable this kind of thing, and being a user of JSON-LD I've been hit by this also. In my case, I simply have my JSON-LD documents use the |
@@ -0,0 +1,14 @@ | |||
'use strict'; | |||
require('../common'); | |||
var assert = require('assert'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you use const
here?
Couple of nits regarding the test. LGTM if you fix those and squash the commits. |
The JSON-LD standard (http://www.w3.org/TR/json-ld/) requires sending what is effectively JSON content using a different MIME type. Because of that, it is usually required to use a file extension other than .json since that is what is typically used in MIME type mapping in HTTP servers. The IANA-registered file extension is .jsonld (http://www.iana.org/assignments/media-types/application/ld+json). This patch makes .jsonld documents loadable through require() in the exact same manner that .json files are.
@bnoordhuis Changes applied, squashed, and pushed. Thanks! |
Thanks, LGTM. CI: https://ci.nodejs.org/job/node-test-pull-request/633/ Before I land this prematurely, does anyone feel this should be discussed more or be brought up at the next TC call? |
LGTM |
I'd like to hold this one off until we get a @nodejs/tsc discussion on this, I'm really not sure we should be adding anything new to |
This was discussed on the CTC call today. Consensus decision was not to land this change, largely because (a) it opens up the possibility of a slippery slope with other formats that others may want to support and (b) since JSON-LD is really just JSON, there's a simple workaround. If you look at https://www.npmjs.com/package/activitystreams-context, you can see an example of a module that loads JSON-LD using the *.json file extension. For all reasonable cases, this works well enough and using the *.jsonld file extension is not strictly required. |
Just noticed this PR.
Am I getting it correct that you wanted an
The correct way to process a small json file is to read file first (and do that in an async way) and then do a json parse. The correct way to process a huge json file containing a lot of separate entries involves a streaming json parser. |
I won't object to the decision further, but I feel that the rationale for rejecting the change is unconvincing:
|
@ChALkeR This does not promote anything that isn't already supported, the goal of the PR is simply to avoid special-casing some types of JSON and/or introducing non-idiomatic dirty workarounds (which we have to do now, and it seems will have to continue doing). |
@darobin ... in those cases, the only fallback would be the workaround the @Fishrock123 suggests, albeit keeping in mind that the workaround involves using an undocumented and unsupported "feature" |
@darobin What's your exact use-case, once again? |
Btw, one more thing to note: Refs: |
@jasnell I know. We don't want to go there, sticking with the unpleasant special-casing hack we have rather than switching to an unpleasant unsupported-feature hack is better :) I guess that groups with "TC", "WG", etc. in their name tend to lead to this sort of trade-off. @ChALkeR I'm not sure what's unclear? The use case is to load JSON in the same manner that |
@darobin Guessing that this is not theoretical, so I suppose that you have some app where you want to utilize that.
|
@darobin As for the The doc clearly states:
This is neither of those. For this PR to properly get in (even putting all the other uncertainty aside), the stability index should be first lowered, and my guess would be that it doesn't worth that. |
@ChALkeR Indeed, it's not theoretical; it wouldn't make for a very interesting theoretical case :) It is both server and client, in fact many of the JSON-LD files we have are part of libraries that we reuse in various places. The server loads these files and uses the information in order to process things (e.g. to know that a given type found here is equivalent to another). Some client apps will load them at build time (where the lack of support for loading I guess "bug" is in the eye of the beholder :) Anyway, I disagree with the decision but I don't want to insist for something rather small. |
@darobin ... on possible approach you could take here is to do a polyfill wrap around the built-in |
@darobin I'm pretty sure that you have something wrong in your use-cases. Note that |
I belive that require.extensions should be used instead of |
Here's your slippery slope https://en.wikipedia.org/wiki/List_of_XML_markup_languages And yes, XML might have been a mistake to all us now enlightened folks, but we're now using JSON for basically the same things that we were using XML for and filename extension bloat is inevitable as people come up with specific variants. If we add |
The JSON-LD standard requires sending what is effectively JSON content using a different MIME type. Because of that, it is usually required to use a file extension other than
.json
since that is what is typically used in MIME type mapping in HTTP servers. The IANA-registered file extension is.jsonld
.This patch makes
.jsonld
documents loadable through require() in the exact same manner that.json
files are.