Deno: About package.json

[webia1]

First of all, thank you very much. I think deno with built-in typescript support is a great idea.

But I don't think that package.json was a bad idea.

You could improve it, for:

• repetitive workflows and scripts
• application configuration for different environments
• linter, prettify rules
• maintainer information, licensing, etc
• even for docker building

and so on. It could be the single point of truth without any polling configuration files lying around wild.

[mojila]

I agree with you about 4th point, because when i build deno i've just write about me as author in main script comment

[tunnckoCore]

@webia1, You can still use it, deno just won't take it into account.

i've just write about me as author in main script comment

That's better.

[getspooky]

@webia1, This request seems similar to https://github.com/denoland/deno/issues/47

[webia1]

@webia1, This request seems similar to #47

Thank you, @getspooky; it is a kind of similar, and I think that maybe an ongoing discussion.

I would like to write about licensing (a very complicated topic within the EU):

A central information point (packaging and licensing) would be necessary for us (especially in Germany/EU). It would currently be challenging to get deno free through security, licensing, and data protection departments.

Every big company has very restricted proxies, and it would take I guess two years to enable "https://deno.land/std" till every IT Security Manager knows what deno is. (We have actually still difficulties with some npm-packages trying to get information from other distributed sources)

In principle, they are always very lazy, and as long as there are no automatic tools to fish out the license information from countless files that are loaded by import statements. And these tools have to be approved by them first, and that also takes two years.

What they currently know is: package.json

[crowlKats]

maintainer information, licensing, etc

Ryan has explicitly mentioned in his talks that such information is complete boilerplate.
If the project is ie on github, you know who the author is. Continuing with the github example, you will also have a LICENSE file in the root usually.
And these are not github specific

[nayeemrmn]

@webia1 Just have a package.json in your projects then. You haven't said what Deno should consume this file for. You just like the concept of a package.json in your projects containing this information? That's great, Deno doesn't stop you from adding one.

[webia1]

Dear @nayeemrmn, thank you, but I cannot share your opinion.

Imagine you have to update a particular package (I don't know maybe "crate" is a better name in this context): You have to update every single file containing this package/file/.. Perhaps this update does not change something except a security patch. Would it be nice to do it in one place only?

Even if deno does not stop me adding package.json, it merely does not affect anything. After an application (usually) does not exist from a single file, how can I ensure that there is something like a "project scope"? Where can I best do that? How should my IDE learn about it? Where is my starting point?

The last one is a question of understanding: How does my idea learn about external files (before I even execute the program and download the libraries), how does code completion work within my IDE?

[nayeemrmn]

Imagine you have to update a particular package (I don't know maybe "crate" is a better name in this context): You have to update every single file containing this package/file/.. Perhaps this update does not change something except a security patch. Would it be nice to do it in one place only?

We have the deps.ts convention for that: https://deno.land/manual/linking_to_external_code#it-seems-unwieldy-to-import-urls-everywhere. This is a duplicate of many issues.

After an application (usually) does not exist from a single file, how can I ensure that there is something like a "project scope"? Where can I best do that? How should my IDE learn about it? Where is my starting point?

It's not simply that "Deno has no way of declaring a project root", Deno has no concepts which _depend_ on a project root. It's your IDE and workflow that want one, so your IDE should have a way, which it does.

The last one is a question of understanding: How does my idea learn about external files (before I even execute the program and download the libraries), how does code completion work within my IDE?

Questions are for the discord -- but if you're trying to make a point here I don't know what it is. Remote dependencies _always_ need to be downloaded first for code completion, no matter how they're managed.

[webia1]

ok, thank you, I don't want to stop you then, good luck,..