Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

2024-03-05 Meeting notes #17

Merged
merged 3 commits into from
Mar 27, 2024
Merged
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
37 changes: 37 additions & 0 deletions meeting-notes/2024-03-05.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,37 @@
# Package Meta Interop Collab Space

## Attendees

* Rick Markins (@rxmarbles)
* Jordan Harband (@ljharb)
* Ethan Arrowood (@Ethan-Arrowood)
* Luke Karrys (@lukekarrys)
* Geoffrey Booth (@GeoffreyBooth)
* Darcy Clarke (@darcyclarke)
* Robin Ginn (@rginn)
* Wes Todd (@wesleytodd)
* Steven (@styfle)
* Trivikram Kamat (@trivikr)

## Agenda

* `devEngines` proposal

## `devEngines` proposal

* Presented in [#15](https://github.com/openjs-foundation/package-metadata-interoperability-collab-space/issues/15)
* @darcylarke has concerns on adding a third field and has given a more verbose explaination in [npm cli #7253](https://github.com/npm/cli/pull/7253#issuecomment-1965846137)
* @ljharb still feels this should be added regardless of it being a top level field or not, just due to functionality being applied
* @wes ??? (accurate)
Copy link
Collaborator

@lukekarrys lukekarrys Mar 6, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* @wes ??? (accurate)

This was due to me missing what Wes said but I added it anyway in case someone else was able to fill it in. We should probably just remove this line.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@wesleytodd do you recall what you had mentioned here?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well clearly it was accurate and brilliant 😄

Copy link
Collaborator

@wesleytodd wesleytodd Mar 6, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very accurate 🤣. No I am not sure what said but I am fine if we just delete.

* @darcyclarke engines are currently supported to various degrees by all package managers and should be leveraged because it has overlapping capabilities of the newly proposed devEngines
* @lukekarrys concerns of repurposing something that used to mean one thing that would mean somthing else that can confuse end users
* @darcy linked to npm's own docs on [engines](https://docs.npmjs.com/cli/v10/configuring-npm/package-json#engines) and showed examples of each package managers respecting engines and erroring if the wrong engines.$package-manager is used
* @geoffrey how would using engines to specify package manager stop other package managers from being run? it could only specify all managers as top level keys in engines
* @wesleytodd specifying two ways (packageManager and devEngines) to do the same thing is a mistake and should make a hard break in favor of a single way to do something
@styfle prefers `packageManager` but `devEngines` could work too - more interested in what happens when this field is defined and what tool will actually download the package manager? corepack? something else?
Ethan-Arrowood marked this conversation as resolved.
Show resolved Hide resolved
## Representation

* @ethanarrowood Need more representation from other stakeholders involved to help with this effort
* Was commented that possibly timezones being an issue

## Notes