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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Auto-fetch missing packages. #17

Open
ericelliott opened this issue Jul 7, 2015 · 13 comments
Open

Auto-fetch missing packages. #17

ericelliott opened this issue Jul 7, 2015 · 13 comments

Comments

@ericelliott
Copy link
Contributor

馃幐 馃敟

See also: stampit-org/stampit#147

@nkbt
Copy link
Contributor

nkbt commented Jul 7, 2015

That would be neat. Manipulating npm itself 馃槇
I actually have an idea not to install them globally, but locally. With a very little update to the scaffolds-finder, so it can handle both global and local ones.

@nkbt nkbt self-assigned this Jul 7, 2015
@ericelliott
Copy link
Contributor Author

Some ideas. Feel free to ignore if your are better.

Local install is a great idea so you'll consistently use the same version of the scaffold throughout.

But you should also cache globally, even if you install local.

Before you do anything, check local cache, global cache, then npm and record the following logic results as a list of tasks to perform.

If there is no global cache hit, install global.

If npm is newer than global, update global.

If npm is newer than local, notify in console, but don't update local.

If there is no local install, install from global cache.

Example scenario: global cache found, outdated, local cache not found.

After the logic steps are complete, it should create the following command sequence:

const instructions = [
  'update global',
  'install local'
];

Once you have the sequence, running them is basically a map over the instructions:

const responses = instructions.map(runCommand);

If there are errors, don't dump an error log to disk. Just log to stderr and roll back. You did remember to hold onto the previously installed version, right? ;)

@ericelliott
Copy link
Contributor Author

p.s. - local install always installs from global cache.

@nkbt
Copy link
Contributor

nkbt commented Jul 7, 2015

The issue with auto-install globally is that you may need root for that. Not everyone uses nvm. So I'd suggest not to write global deps at all. Taking scaffold from global dep is okay, writing local is okay, writing global is not okay.

Caching is something npm is taking care of, so we do not need to mess with it at all. Just run internal npm command to install dependency should be more then enough.

@ericelliott
Copy link
Contributor Author

OK.

@ericelliott
Copy link
Contributor Author

Is this done?

@therealklanni
Copy link

What about having a ~/.cf.config.json where you can specify custom "stacks", similar to package.json's dependencies?

This also brings up the question if CF should respect semver. I only mention this because there was some mention here about auto-updating (in addition to auto-fetch).

Sample ~/.cf.config.json (or ~/.cf.json?). Package names and semvers here are made-up.

{
  "react": {
    "cf-react": "^2.4.0",
    "cf-cerebral": "^1.1.3"
  },
  "express": {
    "cf-express": "^1.6.2",
    "cf-passport": "^2.1.4",
    "cf-lodash": "^3.2.1"
  }
}

Running cf install express would look for a stack config of that name in ~/.cf.config.json and use those packages to scaffold, or otherwise use the default stack.

Just thinking out loud here.

@nkbt
Copy link
Contributor

nkbt commented Aug 15, 2015

@ericelliott, no it is not done yet, still in todo. It is blocked by "Search for packages locally #33" (just created). When it is completed, we can then quite easily auto-install packages to the local npm_modules dir and pick them from there to proceed with generation.

@therealklanni I would prefer no to add any additional configs. Any configuration adds complexity and conventions. Very often - unnecessary. This task can be quite easily solved without any additional configuration.

@ericelliott
Copy link
Contributor Author

Great. =)

@nkbt
Copy link
Contributor

nkbt commented Sep 1, 2015

As soon as #33 is there, I'm going to close this one soon.

@ericelliott
Copy link
Contributor Author

We can close this now, right?

@nkbt
Copy link
Contributor

nkbt commented Sep 2, 2015 via email

@ericelliott
Copy link
Contributor Author

Oh. =)

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

3 participants