strongloop/loopback-cli

Make available LB versions configurable

dhmlau opened this issue · 7 comments

dhmlau commented

Overview

As an API Connect user, I would like to provide a value to the LoopBack CLI tooling using an environment variable which will allow me to bypass the version selector that determines which major version of LoopBack I am using.

Acceptance Criteria

  • Modify the loopback-cli's generator steps so that they check for the LOOPBACK_VERSION environment variable

  • If the variable:

    • exists
    • is a valid non-negative integer
    • is one of the available options (2 or 3)
    • set that value to skip the version selector prompt

  • If the variable is not valid (but does exist)

    • emit a warning that the version variable's value is invalid
    • continue with prompting as normal

  • Add test coverage

  • Write JSDoc for the new environment variable

  • Document the new feature in loopback.io

  • Release to npmjs

  • Notify the API Connect team of the new environment variable change

=================================
Original Post:
For Velox, it is using loopback-cli directly. It would be good to have a way to configure what versions are available to users.

From the discussion thread with @raymondfeng and @kraman, one of the possibilities is to make it configurable through environment variable.

cc @raymondfeng

kjdelisle commented

Rejecting this due to incomplete criteria.

  • What is the scenario that describes what we're trying to achieve?
  • What is meant by "configuring versions available to users"?
  • When we say "versions", do we mean "latest major version streams", or do we mean arbitrary selection of releases? (2.0.0, 2.0.1, 2.0.2, etc...)
  • What is the UX scenario that demonstrates the expected behaviour? (example terminal input/output to describe what you want to see)
  • Are we providing the prompt or is it handled by Velox?
  • What environment variables are you looking for? (names and purpose of each should be a part of the criteria)
dhmlau commented

What is the scenario that describes what we're trying to achieve?

In Velox, when running the apic command, it allows users to select using LB2.x or LB3.x for creating LB app. (See details here). Since it is using loopback-cli directly, we cannot filter that using apiconnect-cli (similar node modules as APIC 5.x). OM's decision is to allow users to create LB3 application only.

What is meant by "configuring versions available to users"?

Actually, to be precise, to allow Velox team to have a way to filter out LB2 as one of the options.

When we say "versions", do we mean "latest major version streams", or do we mean arbitrary selection of releases? (2.0.0, 2.0.1, 2.0.2, etc...)

2.x and 3.x as shown in the ticket above

What is the UX scenario that demonstrates the expected behaviour? (example terminal input/output to describe what you want to see)

scenario shown in here

Are we providing the prompt or is it handled by Velox?

From my understanding, the prompt is provided in loopback-cli, Velox is using it as-is.

What environment variables are you looking for? (names and purpose of each should be a part of the criteria)

When talking to @raymondfeng and @kraman , using environment variable is one of the options (not sure if there are others). The questions would be:

  • is using environment variable the solution?
  • If env var is used, is there some naming convention Velox is using, and we can follow if we want?
    Those are the technical questions that need inputs from @raymondfeng and @kraman. I'd suggest someone to find that out.
kjdelisle commented

2.x and 3.x as shown in the ticket above

See, this is why clarification is so important! The ticket you've linked explicitly asks us to allow bypassing the selection because Velox no longer supports 2.x!
So, that makes it seem like the goal here is to allow an env var to specify which version to use when kicking off app scaffolding.

I'll add what I think the criteria are supposed to be, and you can edit it for accuracy to make sure that I haven't got it wrong.

kjdelisle commented

@raymondfeng @dhmlau Please read the updated description up top and correct any inaccuracies with respect to:

  • the goal
  • the names of variables or lack thereof
  • any additional criteria that are required but not listed

Thanks!

dhmlau commented

As an API Connect user, I would like to provide a value to the LoopBack CLI tooling using an environment variable which will allow me to bypass the version selector that determines which major version of LoopBack I am using.

Actually, API Connect user won't be able to choose, because API Connect team determines it, not the users. I think the description would be something like:
As an API Connect developer, I would like to provide a value to the LoopBack CLI tooling using an environment variable which will allow me to bypass the version selector that determines which major version of LoopBack my API Connect users will be using.

raymondfeng commented

The common practice is to use something like --use-version 3.x to skip the prompt. We just need to add a new option and check the presence before prompting the user with choices.