Skip to content

Initial Scope #73

Open
Open

Description

@jonchurch

First, reading through pkgjs/create-pkg#9 "Project Scope" is an important place to start for getting context on this package and it's intent.

I've been thinking about this tool so much that I got lost in it, essentially. The above linked project scope helped me better see the intent for this package.

So to begin with, it's my personal opinion that this package should do a few straightforward things for the initial scope:

  • Create a base package.json file
    • Prompt CLI users for input for a subset of fields
    • Expose a JS API to write a package.json to disk
  • House defaults for what the "base package.json" should be.
    • Specifically, I think that these defaults should be what is currently the defaults for npm init

So more or less, feature parity with the current state of npm init is what I believe initial scope should be.

I'd love to see that include "additive editing", i.e. running npm init -y in a project that already has a package.json will not overwrite your the file, but will fill out any defaults yours is missing (such as repo links if a git repo is present). This is my opinion, and I think this issue is a great place for discussion for/against what an MVP of this package looks like.

In the future I'd like to see features such as:

  • Validation -- is the package.json (and the input for CLI prompts) valid according to defaults set by this package, or settings passed to the package from userland.
  • Default configuration. The bread and butter of this package. Allowing users to define what defaults, prompts, and valid data looks like for their package.json needs.

Activity

  1. wesleytodd commented on Oct 2, 2023

    @wesleytodd
    Member

    I think I am in 100% agreement on the above. The goal is that the 1.x release would be just a bit more than npm init -y but not yet covering more than some sensible defaults.

    Validation

    This is tied in with the collab space work. I think we would want a separate pacakge to validate the package.json, but that could then be used by this one.

    Default configuration

    Ideally folks can layer on top of our opinions with their own defaults. But yes I think the initial goal from the PMWG was to have a place to setup default configurations which follow "best practices".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions