yarnpkg / yarnpkg/berry

[Feature] pack/publish non-workspace folder

Open
#705 20 comments 16 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement
Dominant language
TypeScript
Stars
8.1k
Forks
1.3k
PR merge metrics
No merged PRs in 30d

Description

  • I'd be willing to implement this feature
  • This feature can already be implemented through a plugin

Describe the user story

As a developer I have a build step in my package but I want to publish a flat package.

For example, my package's typescript sources are in a src subfolder. In the published package I don't want there to be a dist or lib folder with the resulting javascript files. I want the javascript files to be in the root of the published package. See also: the angular package format (spec)
On the other hand, I don't want to have these javascript files dirty my workspace. Our current approach is to have a dist folder which contains the built javascript files, the package manifest and any assets, which then gets published instead of publishing the workspace folder.

Describe the solution you'd like

I'd like to be able to use yarn npm publish and yarn pack to publish folders that are not a workspace.

I can see two ways for this to work at first glance:

  • Like in yarn v1 make the yarn pack and yarn npm publish commands work in any folder, regardless of whether it's a workspace
  • Add a property to tell yarn that we run pack/publish in a workspace, it should actually run in a different folder. This could be
    • a command parameter, but we'd have to pass it with every execution which is annoying and error-prone
    • a property in package.json, but then we'd be adding custom properties to the package.json…
    • a configuration variable, but this folder isn't necessarily the same for every package (e.g. we've currently got <repo root>/dist/@scope/package as output folder)

Describe the drawbacks of your solution

  • Extra complexity in the pack/publish commands
  • Allowing pack/publish everywhere is another way for people to make mistakes + it changes what happens if you run yarn pack in a subfolder of a package

Describe alternatives you've considered

  • Not using yarn 2 (e.g. npm) to pack & publish
  • Making the build output the package folder, but that looks messy and it breaks our setup where we've got an index.js that loads ts-node and then re-exports the src/index.ts file to allow us to run our workspace packages from source within the workspace.
  • Publishing non-flat packages. This is actually what we did in our original project setup four years ago, and it led to issues with secondary entrypoints in packages (@scope/package/entry-point)
  • Implement this as a plugin. This is the most viable alternative imo, but also leads to duplicating a lot of yarn logic

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the yarn pack and yarn npm publish entry points and trace how they determine whether the current folder is a workspace. Compare the proposed non-workspace behavior with the existing workspace behavior, including the subfolder safety concern. Done means both commands can publish a selected non-workspace folder without breaking current workspace packaging.

Written by the indexing model from the issue text.

Assessment

Tech stack
nodejs, typescript
Domain
cli, release
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.