You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Status update and next steps for "pkgjs/create" (create-pkg) #458
@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
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.
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)?
@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.
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.
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.
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.
@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:
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.
@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.
Activity
zackschuster commentedon Apr 13, 2021
i'm very interested in contributing to this effort, if at all possible 😄
rxmarbles commentedon Apr 20, 2021
@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-jsonthat is a dependency ofcreate-pkgI have a project boad setup and we just need to add some more work issues to address the reminaing items in the1.xtodo listmhdawson commentedon Apr 20, 2021
@rxmarbles thanks for the update.
zackschuster commentedon Apr 21, 2021
@rxmarbles @wesleytodd shall we schedule time for the sync at tomorrow's meeting?
jonchurch commentedon Jul 1, 2021
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:
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 commentedon Jul 1, 2021
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 commentedon Jul 1, 2021
@jonchurch @thescientist13 I believe that was the key idea of using
create-pkgwould 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 commentedon Jul 1, 2021
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 commentedon Jul 1, 2021
fwiw i still intend to contribute to pkgjs/create-package-json#58
jonchurch commentedon Jul 15, 2021
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-jsonshould be. I think that package is currently the one to focus on so this initiative can move forward.Copied from that issue for context:
ljharb commentedon Jul 15, 2021
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 commentedon Jul 15, 2021
@ljharb I think that sounds interesting. I don't know if those questions should be asked of the user at the
create-package-jsonlevel or at the@pkgjs/createlevel. I'd assume at the@pkgjs/createlevel, personally.I think that already
create-package-jsonis basically at feature parity withnpm 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 anengines:object? or just aminNodeVersionSupported?". I felt that got in the way of building the actual functionality which is:ljharb commentedon Jul 15, 2021
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 commentedon Jul 15, 2021
That's an excellent illustration, though, for what different defaults for
package.jsoncan do.jonchurch commentedon Jul 29, 2021
Discussed the project at the latest meeting, here are the minutes from our discussion:
Ethan-Arrowood commentedon May 10, 2023
I'm here to finish the swing on this. Lets chat next meeting, define a plan, and then execute.
rxmarbles commentedon May 11, 2023
@Ethan-Arrowood maybe you'll be the one to wrangle in everyone to get it going 😉
mhdawson commentedon Jun 20, 2023
@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.