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

Any plans to rename cli? #28

Closed
js-kyle opened this issue Feb 16, 2022 · 11 comments
Closed

Any plans to rename cli? #28

js-kyle opened this issue Feb 16, 2022 · 11 comments
Labels
enhancement New feature or request major version

Comments

@js-kyle
Copy link

js-kyle commented Feb 16, 2022

Hi there

I was wondering if it would be considered to update the cli to learna-lite in a future version, as opposed to the two ws-* commands? The reasoning behind this would be for ease of development, where developers familiar with lerna could easily recognise the use of this project as lerna like commands, whereas ws-* is not familiar

I'm submitting a Feature request

Motivation / Use Case

Ease of migration and familiarity for developers

Expected Behavior

ws-roller version - > lerna-lite version etc

Other Information

@ghiscoding
Copy link
Member

ghiscoding commented Feb 16, 2022

not really, there are 2 CLIs because run is totally optional (as pointed out in the readme) and the naming came from the original repo name that I had when I created the lib. Migration is easy enough, just do a find and replace lerna run => ws-runner run and lerna version to ws-roller version (same for publish). That seems simple enough to me, and I don't want to have only 1 CLI because I want to keep run as optional package (you won't download it if you don't need it and for you need different CLIs) as oppose to Lerna which is 1 CLI yes but it also requires the users to download the entire library (like or not) and in my monorepo I have never use anything else but 3 commands that I have in Lerna-Lite... so that's the reason that it's 2 CLIs, and I think it's better to keep names that aren't too close to lerna <command> so that users understand that it's not an all in 1 like Lerna was. I also wrote a Migration for Lerna users in the readme, it should be easy enough to follow, you should be done in less than 5 min

Also the reason that I want to keep run separate and optional is because I'm hopeful that some day in the future it will become obsolete because NPM Workspace would be able to run npm scripts in parallel and in topological order, for example these 2 NPM RFCs npm run-series && npm run-parallel and Execute workspace commands in good order would cover what the run command is currently doing.

@ghiscoding ghiscoding added the question Further information is requested label Feb 16, 2022
@js-kyle
Copy link
Author

js-kyle commented Feb 16, 2022

I think it's better to keep names that aren't too close to lerna so that users understand that it's not an all in 1 like Lerna was.

lerna-lite definitely implyies at a glance that it is not the full feature set of lerna

The benefit is that at a glance, any developer on a project can recognise that it is operating similar to lerna. If they have questions they will be able to search for lerna-lite documentation or look at the lerna-lite module. At present ws-* has no correlation to the module name so is pretty confusing in itself. For example searching ws-roller in npm returns no results

But that is just my feedback - take it as you please :)

@ghiscoding
Copy link
Member

ghiscoding commented Feb 16, 2022

I don't see how that could be achievable with 2 separate CLIs, the best I could do is rename ws-roller to lerna-lite but then we would still have ws-runner for run and that is even more confusion, so unless I merge all commands into 1 CLI (which I don't want to do, because I really want to keep run optional) then I don't see this as something doable unless you have better ideas?

@mrchief
Copy link

mrchief commented Feb 24, 2022

Maybe change ws to ll (for lerna-lite). Anything else requires too much work to be able to keep 2 clis and still have the same API

@ghiscoding
Copy link
Member

I don't see how changing ws to ll would help in anything, unless you're trying to say to keep only 1 CLI as ll (which I'll say again I want to keep 2 CLIs). I seriously don't see how hard it can be to in your CI job and do a search & replace, 5min max. You cannot execute run, publish and version at the same time, so I don't see how keeping 2 CLIs is hurting anything.

Keeping only 1 CLI (like Lerna) would mean that run would no longer be optional and I don't want to do that, I have high hope that it will become useless in the future when NPM Workspaces add this functionality and I'm sure certain users of this lib are only interested in the publish/version features and do not wish to download extra bits for run that they wouldn't use. Keeping 1 CLI means nothing is optional (like Lerna, you get all of it, regardless if you use it or not which is what I wanted to avoid)

@js-kyle
Copy link
Author

js-kyle commented Feb 24, 2022

I seriously don't see how hard it can be to in your CI job and do a search & replace, 5min max

This is not about migration - it is the fact that ws-* commands are unrecognisable to developers in a project

@mrchief
Copy link

mrchief commented Feb 24, 2022

ws has no relation that you can derive intuitively to lerna-lite. ll is just lerna-lite abbreviated.

Alternatively, have you looked at making a command runner as part of core that understands version|publish|run as commands and routes them to individual clis as needed?

So e.g., lerna-lite run would look for @lerna-lite/run installed in the node_modules (local or global) and would invoke it if found, otherwise print a warning asking users to install the package

@ghiscoding
Copy link
Member

ghiscoding commented Feb 24, 2022

Alternatively, have you looked at making a command runner as part of core that understands version|publish|run as commands and routes them to individual clis as needed?

So e.g., lerna-lite run would look for @lerna-lite/run installed in the node_modules (local or global) and would invoke it if found, otherwise print a warning asking users to install the package

If you know how to do that and keep the run command optional, I'd be happy to get a PR on this, I personally never created a CLI code before creating this project and there are sections of the original Lerna CLI that I don't fully understand how it all work.

I'm currently mostly focused on adding most of Lerna's unit tests as much as possible so that we can add features without stressing too much.

Also if anyone think they have a better approach/code with certain things and it makes more sense then go ahead with PRs. My main goal was to replace Lerna in my own monorepo with something that was smaller which doesn't have too much out of date dependencies. However, the only thing that I really wish to keep separate and optional is the run command.

@mrchief
Copy link

mrchief commented Feb 24, 2022

I'm looking at replacing lerna and I've been following the "lerna is largely unmaintained topic" so I'm aware of the work in general. I currently use a combo of release-please and lerna to manage prereleases, beta packages and releases and I would like to avoid having 2 ringmasters. You're doing great work and we appreciate all the effort. Your philosophy is sound but we also need to manage developer expectations and overall experience. I'd try to see if I can send a PR but work's been hectic lately and it may not pan out as quickly, so no promises! :)

@mrchief
Copy link

mrchief commented Feb 25, 2022

Spitballing here but something along these lines

// packages/cli.ts

async function runHandler(argv: any) {
  logCliVersion();

  try {
    const { handler: RunCli } = await import('@lerna-lite/run');
    RunCli(argv);
  } catch (e) {
    console.error(
      '@lerna-lite/run not found. Please install it with `npm install @lerna-lite/run`'
    );
  }
}

yargs
   ...
   .command({
    command: 'run <script>',
    describe: 'Run an npm script in each package that contains that script',
    handler: runHandler,
  })

// packages/run/cli
function handler () ...
yargs...
...
export { handler }

@ghiscoding ghiscoding added the help wanted Extra attention is needed label Mar 1, 2022
@ghiscoding ghiscoding added wip work is in progress and removed help wanted Extra attention is needed labels Mar 10, 2022
ghiscoding added a commit that referenced this issue Mar 15, 2022
BREAKING CHANGE: use `lerna` CLI for all commands, fixes #28
@ghiscoding ghiscoding added enhancement New feature or request and removed question Further information is requested wip work is in progress labels Mar 15, 2022
@ghiscoding
Copy link
Member

After few days working on this, the feature is in, so hopefully this will clear the last hurdle for people who want to migrate from Lerna to Lerna-Lite. I basically copied over the original Lerna CLI and even used the exact same name so it's a full drop-in replacement, just swap Lerna to Lerna-Lite in your dependencies and you'll be good to go. See the new release and I decided to make it a major as 1.0.0

I also implemented what @mrchief suggested so that I could keep run as an optional package and I just tried it in my own repo to not install it and as expected I get the error that was suggested.

So hopefully everyone can enjoy it and I can close the subject and move on to something else 😉

image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request major version
Projects
None yet
Development

No branches or pull requests

3 participants