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

What does Yarn 1.0 mean? #3371

Closed
3 of 8 tasks
bestander opened this issue May 10, 2017 · 5 comments
Closed
3 of 8 tasks

What does Yarn 1.0 mean? #3371

bestander opened this issue May 10, 2017 · 5 comments

Comments

@bestander
Copy link
Member

bestander commented May 10, 2017

  • get issues under control: categorized, critical ones fixed, with a plan to solve the majority of outstanding ones (POC @bestander)
  • introduce breaking changes that we did not do pre 1.0 (e.g. npm@5 changes to lifecycle scripts)
  • fix pack and publish commands and experience
  • workspaces
  • make CI stable
  • start CLI performance improvement project
  • Cleanup release artifacts from having dist folder (POC @Daniel15)
  • Deal with technical debt (less stateful resolve/fetch logic) (POC @arcanis )
@cpojer
Copy link
Contributor

cpojer commented May 11, 2017

  • Consider yr (or similar) to reinvent running scripts. Similar to https://github.com/kentcdodds/nps.
  • Re-architect Yarn based on experiments by @arcanis.
  • Find some testimonials about how Yarn helped them for the blog post.

@arcanis
Copy link
Member

arcanis commented May 11, 2017

Consider yr (or similar) to reinvent running scripts. Similar to https://github.com/kentcdodds/nps.

An issue that we might have to consider: it will be hard to ship Yarn as a single file if we do this. Possible solutions are: making yr optional, or using process.argv0 to launch the right binary depending on how the script has been invoked (similar to what busybox is doing).

@Daniel15
Copy link
Member

Daniel15 commented May 12, 2017

An issue that we might have to consider: it will be hard to ship Yarn as a single file if we do this. Possible solutions are: making yr optional

We could make yarn run awesome (or a new yarn awesome-run or something like that), and then have yr simply be an alias for it. If you use the tarball version of Yarn (or the Windows installer or Homebrew package or whatever else), yr could simply be a shell script that runs yarn run $@. People that use the single-file build can simply create the shell script themselves 😛

@cpojer
Copy link
Contributor

cpojer commented May 12, 2017

The only thing I care about is that we are careful not to introduce breaking changes. We can build things outside of the current "scripts" package.json field, but only if we also support the old way of doing things.

@bestander
Copy link
Member Author

bestander commented May 22, 2017

As @rally25rs suggested (cleaned discussion), let's do "Project" with milestones to track progress.
Never used it before but created the project here https://github.com/yarnpkg/yarn/projects/3.

My plan is to track 1.0 progress via the project.

Also I removed non actionable (anymore) comments.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants