Support for package.xxxx (dedicated)

[LongTengDao]

What is the problem this feature will solve?

JSON is a good data transfer and built-in-js format.

But:

1. it's really uncomfortable for human reading/writing
2. json config file is ubiquitous and day after day cost really too much
3. config file seemed a very small percentage of a package, but it's the face, like api for a lib, or cli for a binary program, actually mainly deal with

The related issue #40714 which is closed maybe request too much, too heavy change, including both parse and stringify, package even import/require/JSON.parse.

But in fact, the stringify and import/require/JSON.parse is almost impossible to reach, and also no big necessity. People should better do that via 3rd party runtime lib, even compiling plugins.

Is it possible, that we just support other format like JSON5/YAML/TOML, just in package.xxxx?

What is the feature you are proposing to solve the problem?

Add support for package.json5/package.yaml/package.toml in Node. It means same effect for "main" and other functional fields with package.json.

People can require('./package'), or simply not support that. When people do that for a libary, of cause they should read the package's docs. This can be discussed.

No more.

What alternatives have you considered?

No response

[LongTengDao]

A living example to see the differences:

package.json

{
    "name": "@ltd/j-toml"
    ,
    "description": "An implementation of TOML written by LongTengDao. Belong to \"Plan J\".／龙腾道为汤小明语写的实现。从属于“简计划”。"
    ,
    "version": "1.28.0"
    ,
    "license": "LGPL-3.0"
    ,
    "author": "龙腾道 <[email protected]> (www.LongTengDao.com)"
    ,
    "bugs": "https://GitHub.com/LongTengDao/j-toml/issues"
    ,
    "repository": { "type": "git", "url": "https://GitHub.com/LongTengDao/j-toml.git" }
    ,
    "keywords": [ "TOML", "stringify", "parse", "1.0.0", "0.5.0", "0.4.0", "0.3.0", "0.2.0", "0.1.0" ]
    ,
    "homepage": "https://www.npmjs.com/package/@ltd/j-toml"
    ,
    "files": [
        "package.json"
        ,
        "index.d.ts"
        ,
        "index.js"
        ,
        "index.js.map"
        ,
        "index.d.mts"
        ,
        "index.mjs"
        ,
        "index.mjs.map"
        ,
        "test.js"
        ,
        ".editorconfig"
        ,
        "LICENSE"
        ,
        "README.md"
        ,
        "CHANGELOG.md"
    ]
    ,
    "scripts": {
        "test": "node ./test.js"
    }
    ,
    "exports": {
        "import": {
            "types": "./index.d.mts"
            ,
            "default": "./index.mjs"
        }
        ,
        "require": {
            "types": "./index.d.ts"
            ,
            "default": "./index.js"
        }
    }
}

package.json5

{

    name: '@ltd/j-toml',

    description: 'An implementation of TOML written by LongTengDao. Belong to "Plan J".／龙腾道为汤小明语写的实现。从属于“简计划”。',

    version: '1.28.0',

    license: 'LGPL-3.0',

    author: '龙腾道 <[email protected]> (www.LongTengDao.com)',

    bugs: 'https://GitHub.com/LongTengDao/j-toml/issues',

    repository: { type: 'git', url: 'https://GitHub.com/LongTengDao/j-toml.git' },

    keywords: [ 'TOML', 'stringify', 'parse', '1.0.0', '0.5.0', '0.4.0', '0.3.0', '0.2.0', '0.1.0' ],

    homepage: 'https://www.npmjs.com/package/@ltd/j-toml',

    files: [
        'package.json',
        'index.d.ts',
        'index.js',
        'index.js.map',
        'index.d.mts',
        'index.mjs',
        'index.mjs.map',
        'test.js',
        '.editorconfig',
        'LICENSE',
        'README.md',
        'CHANGELOG.md',
    ],

    scripts: {
        test: 'node ./test.js',
    },

    exports: {
        import: {
            types: './index.d.mts',
            default: './index.mjs',
        },
        require: {
            types: './index.d.ts',
            default: './index.js',
        },
    },

}

package.yaml

name: '@ltd/j-toml'

description: 'An implementation of TOML written by LongTengDao. Belong to "Plan J".／龙腾道为汤小明语写的实现。从属于“简计划”。'

version: 1.28.0

license: LGPL-3.0

author: '龙腾道 <[email protected]> (www.LongTengDao.com)'

bugs: https://GitHub.com/LongTengDao/j-toml/issues

repository: { type: 'git', url: 'https://GitHub.com/LongTengDao/j-toml.git' }

keywords: [ TOML, stringify, parse, 1.0.0, 0.5.0, 0.4.0, 0.3.0, 0.2.0, 0.1.0 ]

homepage: https://www.npmjs.com/package/@ltd/j-toml

files:
    - package.json
    - index.d.ts
    - index.js
    - index.js.map
    - index.d.mts
    - index.mjs
    - index.mjs.map
    - test.js
    - .editorconfig
    - LICENSE
    - README.md
    - CHANGELOG.md

scripts:
    test: 'node ./test.js'

exports:
    import:
        types  : ./index.d.mts
        default: ./index.mjs
    require:
        types  : ./index.d.ts
        default: ./index.js

package.toml

name = '@ltd/j-toml'

description = """
An implementation of TOML written by LongTengDao. Belong to "Plan J".\
／\
龙腾道为汤小明语写的实现。从属于“简计划”。\
"""

version = '1.28.0'

license = 'LGPL-3.0'

author = '龙腾道 <[email protected]> (www.LongTengDao.com)'

bugs = 'https://GitHub.com/LongTengDao/j-toml/issues'

repository = { type = 'git', url = 'https://GitHub.com/LongTengDao/j-toml.git' }

keywords = [ 'TOML', 'stringify', 'parse', '1.0.0', '0.5.0', '0.4.0', '0.3.0', '0.2.0', '0.1.0' ]

homepage = 'https://www.npmjs.com/package/@ltd/j-toml'

files = [
    'package.json',
    'index.d.ts',
    'index.js',
    'index.js.map',
    'index.d.mts',
    'index.mjs',
    'index.mjs.map',
    'test.js',
    '.editorconfig',
    'LICENSE',
    'README.md',
    'CHANGELOG.md',
]

[scripts]

test = 'node ./test.js'

[exports]

import.types   = './index.d.mts'
import.default = './index.mjs'

require.types   = './index.d.ts'
require.default = './index.js'

[aduh95]

Even if I would love to have native TOML support in JS, I'm afraid package.json is way too much engraved in the ecosystem to ever change at this point. Node.js itself has very limited support for package.json (see the docs, we only use 6 fields atm), if we take your example but limit it to what Node.js actually supports, one could argue it's not so bad in term of readability:

{
  "name": "@ltd/j-toml",
  "exports": {
    "import": {
      "types": "./index.d.mts",
      "default": "./index.mjs"
    },
    "require": {
      "types": "./index.d.ts",
      "default": "./index.js"
    }
  }
}

Many other tools in the ecosystem also expect to find a package.json file – e.g.: npm, and we have no control over what npm is doing or supports regarding package.json. If you'd like to see something like this happen, it would need to be accepted by other tools first, otherwise will still need to have a package.json.

A more realistic approach would be to create a script that translates your package.toml in JSON before publishing it to npm, and you'd be half the way there.

People can require('./package')

FYI Node.js also needs to support ESM, which does no extension searching (meaning you would have to do import './package.toml' assert { type: 'toml' }, which is arguably way less transparent).

[LongTengDao]

Indeed there could be problems for node to do this, and I also think this proposal rarely has chance to become true.

I still open this, half because json's problem, and half because, every ecosystem has a root. Maybe it's hard to lead ecosystem move on, but if node can't, nobody can. The other tool stacks of our ecosystem just watch npm and node, and npm will watch node. I can't image, there will be an easier position than node to do this.

[aduh95]

if node can't, nobody can

I'll try not to make the subject too philosophical, but node is not really an entity with a will and an end-goal, it's a community which is supported by volunteers. So I don't think "node" can, but anyone in the community (you maybe?) can try. Here's a list of challenges to overcome for this to happen:

1. Node.js would need to provide a "blessed" parser to each format to support (currently, we only have JSON, provided by V8). Any addition to Node.js core is always controversial, maybe you can check out the discussion in To be or not to be in core TSC#1041, here are a few questions that would need answers:
   • There are a lot of parsers for each format to chose from, how do we pick one?
   • Who is going to maintain that code?
   • You're suggesting to add 3 parsers, but what if someone comes up with 10 other parsers, will we need to add those also? When does it stop?
   • How many security releases will we have to ship because of the added parsers?
2. Node.js internals would need to be updated to take into account the different possible input sources.
3. Other tools in the ecosystem would need to be updated to take into account the different possible input sources.

If you feel like it's something that's worth the effort, you can make it happen as long as no one objects. My guess though is that the majority of Node.js community thinks that JSON is not problematic enough to be worth it (I also think so).

[LongTengDao]

@aduh95 Thank you to crystallize the challenges for this!

It seems that, only support multiple formats for package, won't be much less difficulty than supporting for require/import all.

I close this issue. Maybe one day these question I have good answers, I will reopen this. Currently, I only wrote translation, tutorial and implementation for TOML, that's too few to achieve this purpose.