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

[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.

[zackschuster]

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

[rxmarbles]

@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

[mhdawson]

@rxmarbles thanks for the update.

[zackschuster]

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

[jonchurch]

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.

[thescientist13]

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)?

[rxmarbles]

@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.

[jonchurch]

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.

[zackschuster]

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

[jonchurch]

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.

[ljharb]

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.

[jonchurch]

@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

[ljharb]

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

[jonchurch]

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

[jonchurch]

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

[Ethan-Arrowood]

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

[rxmarbles]

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

[mhdawson]

@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.