Skip to content

Status update and next steps for "pkgjs/create" (create-pkg) #458

Open

Description

@mhdawson

@rxmarbles with catch up with @wesleytodd to see if he can get up speed and then think about setting up a working session to move the coding forward.

Activity

  1. zackschuster commented on Apr 13, 2021

    @zackschuster
    Contributor

    i'm very interested in contributing to this effort, if at all possible 😄

  2. rxmarbles commented on Apr 20, 2021

    @rxmarbles
    Contributor

    @zackschuster we'd be happy to have more help just setup some time w/ @wesleytodd and myself and we can do a sync.

    @mhdawson an update on this. I met w/ Wes and we talked about the project and it's status we have some work to handle on the create-package-json that is a dependency of create-pkg I have a project boad setup and we just need to add some more work issues to address the reminaing items in the 1.x todo list

  3. mhdawson commented on Apr 20, 2021

    @mhdawson
    MemberAuthor

    @rxmarbles thanks for the update.

  4. zackschuster commented on Apr 21, 2021

    @zackschuster
    Contributor

    @rxmarbles @wesleytodd shall we schedule time for the sync at tomorrow's meeting?

  5. jonchurch commented on Jul 1, 2021

    @jonchurch
    Contributor

    Caught up with wes today about this briefly. He hasn't had the time to keep up with current discussions in the repo so things haven't progressed.

    In order to move forward it needs:

    • People who understand the problem the project intends to address and can communicate it in simple terms (aka likely create some tickets to be worked on)
    • Someone(s) who have the time and desire to work on it, make decisions, and push code
    • Edit: Giving commit bits to contributors

    I brought up finding some funding for the project to help someone(s) be able to dedicate time to it. Good candidates would be companies who have an interest in solving problems in the scaffolding landscape, most notably NPM could benefit from this project.

    So classic issues of momentum and human hours being needed to kickstart the project, which could be addressed by someone taking charge and funding being provided. For those who would like to get involved, this existing issue lays out the motivation and imagined project structure.

  6. thescientist13 commented on Jul 1, 2021

    @thescientist13
    SponsorContributor

    Curious, is this intended to scaffold packages (thinking something like Yeoman) or just a package.json?

    I know on the NPM Open RFC call someone was demoing work around for a CLI for managing and interacting with package.json and wasn't sure if there was overlap, or if this project had greater ambitions past just scaffolding a package manifest (package.json)?

  7. rxmarbles commented on Jul 1, 2021

    @rxmarbles
    Contributor

    @jonchurch @thescientist13 I believe that was the key idea of using create-pkg would be used in NPM cli for helping scale up packages easier based on my last convo w/ @wesleytodd. I too agree that some of the issues of getting movment have to do w/ time and resources. I'm able to assist but mostly in free time as work has been taking a lot of my primary focus. Happy to help get momentum going though.

  8. jonchurch commented on Jul 1, 2021

    @jonchurch
    Contributor

    Forgot to mention, actual next steps on this that @wesleytodd mentioned would be giving out some commit bits to contributors so he isn't blocking on PRs etc.

  9. zackschuster commented on Jul 1, 2021

    @zackschuster
    Contributor

    fwiw i still intend to contribute to pkgjs/create-package-json#58

  10. jonchurch commented on Jul 15, 2021

    @jonchurch
    Contributor

    I opened a new issue pkgjs/create-package-json#73 to hopefully get folks on the same page for what the initial scope of create-package-json should be. I think that package is currently the one to focus on so this initiative can move forward.

    Copied from that issue for context:

    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.
  11. ljharb commented on Jul 15, 2021

    @ljharb
    SponsorMember

    In particular, I’d like it to be better than npm init - in other words, not to just prompt for fields, but first ask questions about the package’s intent. Is it a deployed app, or a published package? Is it meant to support node only, browser only, or both? What are the target platforms?

    From those intentions, i suspect most best practices can be programmatically inferred.

  12. jonchurch commented on Jul 15, 2021

    @jonchurch
    Contributor

    @ljharb I think that sounds interesting. I don't know if those questions should be asked of the user at the create-package-json level or at the @pkgjs/create level. I'd assume at the @pkgjs/create level, personally.

    I think that already create-package-json is basically at feature parity with npm init, I just want to specify that baking in defaults shouldn't be a blocker for the tool's core functionality being developed. I personally got stuck on trying to figure out small details like "should we prompt the user for an engines: object? or just a minNodeVersionSupported?". I felt that got in the way of building the actual functionality which is:

    • CLI interface
    • Taking input and creating the file
    • Storing/registering opinions and defaults
    • And (eventually) validating a package.json
  13. ljharb commented on Jul 15, 2021

    @ljharb
    SponsorMember

    Ah, true - i'd expect "create package" to ask those questions, and use them to call into the more basic/explicit "create package.json".

  14. jonchurch commented on Jul 15, 2021

    @jonchurch
    Contributor

    That's an excellent illustration, though, for what different defaults for package.json can do.

  15. jonchurch commented on Jul 29, 2021

    @jonchurch
    Contributor

    Discussed the project at the latest meeting, here are the minutes from our discussion:

    • In past, request for changes/extensions to npm init
      • package maintenance team could provide good defaults. One key goal is to move
        Towards instead of running npm init, run npm init pkg which would run the
        create-pkg module to do the initialization.
    • should have directory of examples, have tests output one of every variant then do
      snapshot testing.
    • darcy has create-pkg, repo is https://github.com/pkgjs/create
    • Main current state is not merged yet. For create-package-json you need to look at 1.x
      branch - https://github.com/pkgjs/create-package-json/tree/1.x
  16. Ethan-Arrowood commented on May 10, 2023

    @Ethan-Arrowood
    Contributor

    I'm here to finish the swing on this. Lets chat next meeting, define a plan, and then execute. :blob_pray:

  17. rxmarbles commented on May 11, 2023

    @rxmarbles
    Contributor

    @Ethan-Arrowood maybe you'll be the one to wrangle in everyone to get it going 😉

  18. mhdawson commented on Jun 20, 2023

    @mhdawson
    MemberAuthor

    @Ethan-Arrowood we discussed in the team meeting today and @wesleytodd volunteered to sycn up with you and help bring you up to speed with the work he'd already done on this front.

    Maybe it makes sense for you and @wesleytodd to get together and document the plan.

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

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions