[FOLIO-2092] use -alpha.NNN pre-release version syntax in npm-folio artifacts Created: 10/Jun/19  Updated: 08/Feb/21

Status: Blocked
Project: FOLIO
Components: None
Affects versions: None
Fix versions: None

Type: Story Priority: P2
Reporter: Zak Burke Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: platform-backlog
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Relates
relates to FOLIO-1704 Expose next-major features/migration ... Open
relates to UXPROD-2066 CI architecture and process to allow ... Closed
relates to FOLIO-2138 Version numbers of npm managed backen... Closed
Sprint: CP: ready for planning
Story Points: 5
Development Team: Core: Platform

 Description   

When a PR is merged to a UI library such as stripes-core or ui-users, our CI process inflates the patch-number and publishes an NPM to npm-folioci. This can cause all kinds of problems, such as trouble with lock files and other issues related to the differences among how dependencies are resolved in CI, developer environments, workspaces, platforms, etc.

We should investigate whether it would make sense to publish pre-releases, i.e. -alpha.NNN, straight to npm-folio, and to abandon npm-folioci. This would have the benefit of eliminating any differences between dev/prod/CI environments while still allowing developers to depend on commited-but-unreleased (i.e. “alpha”) features in libraries.

There are some wrinkles/risks:

  • somebody might formally release something with a -alpha.NNN dep, which currently cannot happen because those pre-release versions never show up on npm-folio.
  • `~` and `^` comparators DO NOT match pre-releases. This means we could be trouble when building a platform and apps ask for two different releases, e.g. "@folio/stripes": "^2.7.0" and "@folio/stripes": "^2.8.0-alpha.001". Apps depend on @folio/stripes only as a peer, to be provided by the platform, so this may just be a problem in workspaces where we’ll see an “unmet peer dependency” warning.

See also https://medium.com/@mbostock/prereleases-and-npm-e778fc5e2420, in particular the note that -alpha.NNN releases must be published like npm publish --tag foo in order to avoid NPM automatically tagging them as latest and thereby providing them to folks who actually want the latest release, not the latest commit.



 Comments   
Comment by Jakub Skoczen [ 10/Jul/19 ]

Zak Burke it looks like we also need a SPIKE for UI and NPM devevelopers to define requirements for the Platform team. I'll create a ticket for that.

Comment by Zak Burke [ 06/Feb/20 ]

I was thinking about this recently in the context of UIREQ-370 Closed when we backported it to the v1.14 branch. Tests on the PR failed due to changes in the internal HTML markup of a component from stripes-components, not the public API (hence no major version change) when the branch was built against npm-folioci, i.e. master, but then succeeded when publishing the release because that process builds against npm-folio, i.e. using released artifacts.

If we published to only one repository but kept the version on master set to something like v3.6.0-beta.1 and only released from branches where we had versions like v3.6.0 then tests would have passed consistently.

That said, we probably don't want to publish every commit to every repository as a new -beta.nnn release to npm-folio. So ... I dunno. This requires a little more thought than I realized.

Generated at Thu Feb 08 23:18:09 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.