package.json support

[DanielMazurkiewicz]

Supporting json based description of package seems pretty important, even support for incompatible version of package.json would be a plus.

And my personal preference would be also adding an option to load package description as a js object (without necessity of placing quotes) and with possibility to define scripts not only as a shell commands, but also as functions to which command line arguments and environment variables are passed.

{
  name: "[email protected]/ds",
  version: "0.0.0-beta",

  scripts: {
    test: "node test.js" // classic shell script
    compile: function(args, env, shell) {
      shell.run("ts " + args[0]);
    }
  },

  dependencies: {
      "@iarna/toml": "^2.2.3",
      "[email protected]/figgy-pudding": "^3.5.1"
  }
}

Your solution could support all these 3 formats (toml > json > js like)

[chrisdickinson]

We made the decision to switch to Package.toml for a couple of reasons (that really need to be documented in docs/README.md):

• Separates the computer-oriented "manifest" info from the human oriented "shipping" info. That is: a human writes a Package.toml, which the CLI interprets in order to create a derived manifest on the server.
• Only reading Package.toml lets package authors publish a single package to both entropic and legacy registries, and lets them "opt in" to publishing to an entropic instance gradually.
• Entropic package specifications (chris@localhost:3000/example) are invalid in both the name and dependencies key position for legacy packages. Existing CLIs will fail if they see them there, so it forces authors to make an up-front, final decision about which registry they're publishing to, or else swap files on publish.

For these reasons it's pretty unlikely that ds will grow support for reading package.json. That said, I think we'll probably have to emit package.json files when materializing files to disk because Node relies on them to determine, e.g., where the main module lives on disk. (Until Tink or import maps land.)

[toddself]

@DanielMazurkiewicz i just wrote this tool though: https://github.com/toddself/package2toml that will read in your package.json and generate a Package.toml file from it!

[ceejbot]

OH THAT IS SO NICE.

[ForsakenHarmony]

have you considered yaml?

Or at least giving the top level thing a name, because toml is kinda fucked

[toddself]

@ForsakenHarmony personally i've never enjoyed YAML as a specification format. yaml: probably not so great after all covers a lot of the issues I have with yaml.

also rust's cargo files use toml and look very similar to this.

what is about toml you don't like?

[ForsakenHarmony]

The problem with toml is that you can only enter "objects", not leave them

And going by the readme name is top level which you can't get back to after entering something else

Would be good to have that in i.e. [package] like rust

https://doc.rust-lang.org/cargo/reference/manifest.html#the-package-section

[chrisdickinson]

Ah – IIUC, I think the only object where that's a problem is the top level (You can re-enter a non-top-level object using dot notation.) I sort of like that this forces the name to the top of the file, tbh.

[jsumners]

How does switching to Package.toml mesh with the fact that Node directly supports package.json to indicate a module? https://nodejs.org/dist/latest-v10.x/docs/api/modules.html#modules_folders_as_modules

It is convenient to organize programs and libraries into self-contained directories, and then provide a single entry point to that library. There are three ways in which a folder may be passed to require() as an argument.

The first is to create a package.json file in the root of the folder, which specifies a main module...

Edit:

I see that it has been mentioned this tool might have to emit a package.json specifically for this reason. This is good. I have on my todo list to try and get better relative imports added to Node's require and it would depend on package.json existing (as does a lot of other code out there in the wild already).

[jimmywarting]

First: Love the work you put into entropic and making NodeJS and package manager better!

But why a package file at all? I'm very drawn to dyno way of loading modules.

• Don't need a package.json
• Don't have to install anything, or doing any command stuff
• Loaded on demand (lazy loaded)
• Support async import().then(...)
• all modules are sandboxed
• works for both browser and server with a absolute or relative path

the bad parts are that import don't have SRI support and you lose support for versioning and also decentralization (unless rfc7838 solves that?

Node have made some design flaws but i still love and use it today, Some day i would like to try deno out

"package.json now includes all sorts of unnecessary information License? Repository? Description? WebPack config? and all other noise"

https://www.youtube.com/embed/z6JRlx5NC9E?start=1854&end=2259&version=3 https://www.youtube.com/embed/M3BM9TB-8yA?start=582&end=1601&version=3

[venikx]

@jimmywarting I don't think you lose versioning with deno though, since the urls themselves would/could have versions themselves.

I think what entropy is doing is an alternative to a package manager for node, not an alternative to node itself. So I'm assuming breaking compatibility with the current workflow/concepts with npm would like stay minimal (unless the project is going for a more drastic change).

There are some ideas from deno that could be used with node with something like tink (also an amazing talk from JSConfEU https://www.youtube.com/watch?v=SHIci8-6_gs). Man, so many good talks this year.

[jimmywarting]

I saw Chrome implemented a key/val storage and the way you use it is:

import {storage, StorageArea} from 'std:kv-storage';

So they seems to have prefixed new internal core modules. It would be awesome if we could do something like that. If we could hook into nodes module path resolver somehow and be able to do something like this

import fetch from 'npm:node-fetch@^1.0.5'
import fetch from 'npm:node-fetch' // load latest
import fetch from 'node-fetch' // for backward compatibly 

That would make it awesome! fetch the package on the fly and skip package.json Would only fetch/catch and install the dependencies that you use

But i would still prefer absolute paths so they are able to work in browsers too So i guess i'm more keen to have more like a CDN where you would get all modules from.

import fetch from 'https://cdn.entropic.com/npm/node-fetch@^1.0.5'

[lukejagodzinski]

IMHO support for package.json is crucial for the entropic to be successful. It will never become mainstream if you have to learn from scratch instead of going incementaly. Take a look at elm compared to typescript. The first one is totally new language and its popularity is not huge. TS on the other had can be used incrementally. You can just start with old JS codebase and incrementally add types. If you want entropic to gain popularity it has to be plug-and-play replacement for npm. Yarn is more or less such a replacement for NPM and it's quite popular. But it's just my opinion

[NetOpWibby]

Does Package.toml have to be capitalized or could I name my file package.toml?