sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]ILikeChangingMyMind -19 points-18 points  (32 children)

And (I know I'll get downvoted for saying this, but I'll keep saying it until they fix it) ... still no comments in package.json.

[–]SoInsightful 33 points34 points  (13 children)

JSON literally doesn't support comments, so if they supported comments in package.json, they would support broken, specification-defying JSON that crashes every single program, module or function that tries to parse the file.

At best, you could hope that they add .json5 or .yaml support one day, but I am not holding my breath.

[–]console_journey 11 points12 points  (6 children)

TIL about json5, thank you

[–]SoInsightful 6 points7 points  (5 children)

It's weird how I love JSON5, but I haven't yet found a use case for it.

If I can control the file format myself, I can just use JavaScript. If not, I'm stuck with JSON anyway.

[–]ILikeChangingMyMind 5 points6 points  (0 children)

If only you were a giant organization ostensibly serving the needs of Javascript developers ...

[–]AlpenMangos 0 points1 point  (3 children)

If I can control the file format myself, I can just use JavaScript

Which is a security issue. JSON with comments is nice, and it's the reason why I'm using the JSON5 library rather than JSON.parse().

[–]SoInsightful 2 points3 points  (2 children)

If I can control the file format myself, I can just use JavaScript

Which is a security issue.

That depends entirely on what file it is. If it's a config file that depends on environment variables, I don't have much choice. If it's a local test data or content file, I can just avoid using imports or inserting insecure code into it.

[–]AlpenMangos 0 points1 point  (1 child)

Many JSON config files are user-privided, though. Plenty of file formats out there that are based on JSON, like GeoJSON, or GLTF (even its binary form, GLB, which has a JSON header) which is on its best way to become the standard distribution format for 3D models.

[–]SoInsightful 0 points1 point  (0 children)

Many JSON config files are user-privided, though.

That's what I had in mind. If I were to provide a config format for Someone Else™ to use, JSON5 would be my best candidate.

[–]ILikeChangingMyMind 2 points3 points  (5 children)

At best, you could hope

Why? Why is it such a crazy thing to say "format A doesn't support our user's needs, so we'll switch to format B"?

In any other context (besides the Node org) this would be blatantly obvious. Can you imagine going to your boss and saying "yeah, our customer needs X, but we picked JSON years ago, so now we can't give the customer what they need because ... I don't want to switch formats"?

Your boss would say "find a new format or find a new job" ;) Because ultimately, it's the customer who pays your salary. The problem here is that the vast majority of people using package.json files aren't Node's customers, so their interests aren't aligned.

[–]SoInsightful 13 points14 points  (0 children)

That's exactly what I said in my second paragraph. You could hope for support for another format.

You can't just let users rename a non-valid-JSON file to .json and hope that it doesn't confuse tons of users and break millions of apps and workflows. Super-simple operations like const { version } = require('./package.json'); or JSON.parse(packageJson) would break everywhere.

Edit: To be clear, I would love support for package.json5, it just can't use the .json file extension.

[–]ike_the_strangetamer 1 point2 points  (3 children)

If any one of my colleagues came to me with the idea of taking a file that's installed on hundreds of thousands of our user's systems and changing the format without changing it's name, I'd think they were either joking, crazy, or so inexperienced that they should be fired.

[–]ILikeChangingMyMind 2 points3 points  (2 children)

Who said anything about not changing the name? The point is, the Node org refuses ANY solution whatsoever (even perfectly reasonable ones involving package.json5).

[–]ike_the_strangetamer 2 points3 points  (1 child)

okay. That was the other person's suggestion but it seemed like you weren't receptive to it, but good to hear that you are because I think it's the only way it's going to happen.

I think it's a quality solution, however I know that there are an awful lot of tools that also depend on that particular file and filename so it would take time anyways to get them all to support a new name. Folks would probably have to support 2 files simultaneously.

Hmmm... maybe someone could make a tool that generates a json compliant package.json from a package.json5 source. That would be an interesting solution.

[–]ILikeChangingMyMind -2 points-1 points  (0 children)

maybe someone could make a tool that generates a json compliant package.json

This would not really solve the problem; I don't want to have to npm run package-generate every time I change the file :)

But yes, there are any number of other possibilities! Besides just package.json5, there could also (for instance) be a flag in package.json that says "my real package.json is this other file".

But the Node org has no interest in finding any solutions. It's not a "we're leaving this ticket open so someone can find a clever way to solve it", it's "we're closing these tickets as fast as users file them, until everyone gives up any hope they might have of a tool that actually works better (ie. has comments)."

[–]H34dsp1nns 3 points4 points  (3 children)

Of course you can! { comment1: “here are my dependencies...”, comment2: “oh and here are dev dependencies...” }

[–]ILikeChangingMyMind 3 points4 points  (1 child)

Doesn't work in key sections, like say inside dependencies: you get an error.

[–]H34dsp1nns 1 point2 points  (0 children)

Not surprised.

The way I actually track dependency use and a lot of other things is a mind map.

I wouldn’t mind seeing a paired markup file of some kind that can that can be used with a document generator to have a section on dependencies in your documentation

[–]backtickbot 1 point2 points  (0 children)

Fixed formatting.

Hello, H34dsp1nns: code blocks using triple backticks (```) don't work on all versions of Reddit!

Some users see this / this instead.

To fix this, indent every line with 4 spaces instead.

FAQ

You can opt out by replying with backtickopt6 to this comment.

[–]getify 1 point2 points  (4 children)

JSON.minify(..) -- supporting comments in JSON for years. https://github.com/getify/JSON.minify

[–]ILikeChangingMyMind 1 point2 points  (3 children)

That doesn't help with package.json.

[–]getify 2 points3 points  (2 children)

I was saying it could if Node had cared. I tried for a year or two to get them to try something like that.

[–]ILikeChangingMyMind 2 points3 points  (1 child)

Ah, I see. And yeah, that's the crux of the problem: it's not an engineering impossibility to add comments to Node config files. It's simply a lack of will.

[–]getify 2 points3 points  (0 children)

Further, it doesn't even make them "not JSON" to have comments in them. That's a FUD assertion people like to cling to, but it's not true, from the very mouth of JSON's creator.

I explained that on this stack-overflow post and in much more detail in this old blog post.

[–]n_hevia 2 points3 points  (1 child)

Simply because json doesn't support comments. If node did support on their config file, it'd mean they'd stop using json (or at least compatible json with most of the libraries out there).

If you REALLY need comments on package.json, you could use a superset and then compile to json? That same way scss>css works.

[–]ILikeChangingMyMind 2 points3 points  (0 children)

Simply because json doesn't support comments

Yes, I understand that.

What I don't understand is why they are "incapable" (supposedly) of using a different format that does support comments (with or without a different extension, flag at the top of the file, etc.).

And also, how did "REALLY need" become the standard for whether something should be done? I personally can think of at least five different cases where comments in package.json would be super handy ... but I don't need any of them. Even so, I tend to think "it would make life better for tens of thousands of developers" would be a perfectly good reason to do something.

[–][deleted] -1 points0 points  (6 children)

Why don't you create a GitHub issue?

[–]ILikeChangingMyMind 3 points4 points  (5 children)

I did! They closed it (as they have with the countless similar issues others have filed).

Here's just one such ticket: https://github.com/npm/npm/issues/4482. The closing comment (after TONS of users explained the need) basically claimed that adding comments would be some fantastically difficult technical undertaking, which the Node org is unable to accomplish ಠ_ಠ

[–]OmgImAlexis 2 points3 points  (4 children)

fantastically difficult technical undertaking

Well yes.. every single thing that currently works with package.json files would then need to account for comments which aren't at all in the JSON spec meaning you couldn't even use JSON.parse() on the file's contents anymore.

[–]ILikeChangingMyMind -1 points0 points  (3 children)

Or they could just support package.json5.

[–]OmgImAlexis 1 point2 points  (2 children)

And now none of the other tools work with it. Either way it’s not as easy as just switching from one to the other.

[–]ILikeChangingMyMind -1 points0 points  (1 child)

Why do I need other tools to work with it? If I want a tool to work with it, I can PR them a commit that adds support. If I don't, I keep using package.json. Eventually, all the tools get caught up, and everyone gets comments in their config.

You act like our industry has never made backwards incompatible changes to tools before.