Yarn: Publish lockfile parser as separate npm package

[Daniel15]

Do you want to request a feature or report a bug?
Feature

What is the current behavior?
Yarn lockfile parser is not available as a separate package

What is the expected behavior?
Yarn lockfile parser should be published (eg. as @yarnpkg/lockfile or something similar) so that people can use it in their own apps. Also see #3397

[BYK]

@Daniel15 @arcanis I think we should include this in 1.0 plans if possible since it would be even harder to undo #3397 after 1.0 (breaking change)

[Daniel15]

Would workspaces help with this? I'm not very familiar with how workspaces work, but I understand that they're similar to Lerna in that they help manage when you have multiple npm packages in the same repo?

Otherwise, we could just have a separate deployment process where we manually publish the lockfile parser to npm if it changes. It could be versioned separately as it should be fairly standalone and separate to Yarn itself, right?

[arcanis]

Not sure about adding this to the 1.0 goal - we really need to make it right and I think that would require extra time. A few notes:

• I don't think internal APIs should count as breaking changes. We very explicitly don't support plugins atm, and until then making guarantees about our code and file hierarchy seems perilous. Doing it too early would lock us without any possibility to fix things.

• That being said, I can see plugins being the target goal for a 2.0 release. 1.0 is about stability, 2.0 could be about modularity.

• The parser should definitely be extracted at some point. It has nothing specific to Yarn (except maybe the newly merged "conflict merge" feature), and makes it harder for people to write tools outside of Yarn (including us).

All in all, I think we should extract the parser to its own package post-1.0, pre-2.0.

[arcanis]

@Daniel15 Yup, workspaces would be the way to go for this. Yarn itself is a good candidate for showcasing the workspace feature 😃

[cdaringe]

i want to vocalize my support of this. dependency reports are so important! if we don't expose the parser soon, can we at least expose a command in the short term to do a JSON dump? that should be cheap and non invasive.

yarn lockfile --json or yarn dependencyReport, etc?

[ggascoigne]

I'd like to add a "me too" to this issue as well, we also have a dependency reporting problem that would be simplified by access to the parser.

[wmhilton]

Should I open a pull request to work on this feature?

[wmhilton]

Is it fair to assume that the lockfile parser/stringifier will be published as a standalone package (so other people can use it in their apps) but the source code will continue to be part of this git repository? In other words, is https://github.com/yarnpkg/yarn going to become a monorepo?

If yarn-lockfile is going to be in a separate git repo, that will make it awkward for files currently used by both the lockfile parser code and the rest of yarn, like constants.js, to be shared between the two repos. However if we keep it in this repo, I think that a the build system could be tweaked to build a second dist build that is just the lockfile parser/stringifier. The philosophical difference being that the yarn-lockfile package wouldn't be a dependency of yarn - rather it would be a by-product produced by building yarn.

[Daniel15]

In other words, is yarnpkg/yarn going to become a monorepo?

I think it make sense to keep everything in one repo 😃

[cdaringe]

for increased vis, im cross posting for interested parties.

I have an interim solution in place for those who need parsing now. see https://github.com/yarnpkg/yarn/pull/4114#issuecomment-321466641