[Feature] Generate package.json for publishing to node npm npmjs.

[gbowne1]

JSONMaestro could be useful for generating package.json files to get users' packages and libraries and modules published to npm/npmjs. This could also be a good tool to check the package.json file to see if it is suitable for publishing and that it contains the necessary keys. It's a json object.

While npm init does a ok job at creating a ok job at creating a boilerplate package.json

npm/npm js only requires the package.json to contain:

"name": "version":

There is no particular order to these that is required for publishing to npm/npmjs, but common practice places these to keys at the top of the json.

Other than those required keys, my research shows that the following keys are the most commonly used when publishing to npm/npmjs

"description" "main" "scripts" "keyword" "author" "license" "repository" "dependencies" "devDependencies" "homepage" "bugs" "private"

Most of these, the key uses strings with a few exceptions like "bugs". They also require a colon and must follow json.

To publish a package to npm, the "private" field should either be set to false or omitted entirely.

There is an included example of package.json, but it generally follows the format;

{
  "name": "your-package-name",
  "version": "1.0.0",
  "description": "A brief description",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": ["keyword1", "keyword2"],
  "author": "Your Name",
  "license": "MIT",
  "dependencies": {
    "package1": "^1.0.0",
    "package2": "^2.0.0"
  },
  "devDependencies": {
    "dev-package1": "^1.0.0"
  }
}

"license" should be an official and valid "SPDX License Identifiers". See: https://spdx.org/licenses/

"name" must be greater that 1, but less than 214 characters and must be a string and lowercase. Can't start or end with spaces. Can't start with a . or underscore. Can't have these ~)('!* in the name. Can't contain spaces. Can't have an non-URL-safe characters. It also cannot and should not be named the same as any other package on the site.

"version" must follow semver.

There are many other keys but they are meant for specific use cases.

in "dependencies" and "devDependencies" keys, there are a few acceptable values for the version of the packages packages and libraries and modules

"1.0.0" - Exact Match "~1.0.0" Tilde version is more restrictive, allowing only patch updates. "^1.0.0" Carat version commonly used as it allows updates to minor and patch releases "latest" will install latest version of dependency "1.0.0 - 1.5.0" Range can use hyphens Range using comparison operators like = < > <= >= Most packages/libraries/modules use Exact, Tilde or Carat versioning in dependencies or devDependencies

We can later on generate or check other iterations of package.json like for a React app, etc.. and Frontend vs Backend package.json file(s).

[gbowne1]

something like jsonmaestro -g package.json would do this nicely. if the user is not intending to publish to npm/npmjs we make "private": true and generate the package.json file.

For a framework / library like React we could something like jsonmaestro -g package.json react.

To validate the package.json for installation we could, 'jsonmaestro -v package.json' (this same method could be used for say, .vscode/*.json files.. it would return a string like "package.json is validated for publishing".

[shoshta73]

This would complicate argument parsing, i dont know how much arguments / flags can click handle

[gbowne1]

yeah it definitely make things very complex.

[shoshta73]

So just base package.json and not doing like basic templates like vite does?

[gbowne1]

to save space we could set it up so that it will not only create a base package.json but also template out other use cases that use package.json like Vite, React, Next, Nuxt, Vue, Angular, Express, Svelte, Gatby, etc.

I considered making a separate tool for doing this but since its json I figured it might be handy.