weldr / bdcs / 220 / 1
85%
master: 85%

DEFAULT BRANCH: master
Ran
Files 62
Run time 2s
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
coverage: 80.952% (-4.9%) from 85.809%
220.1

push

travis-ci

dashea 
Add the beginning of npm import.

When given npm:<name>, import will now download the latest version of
the pacakge from registry.npmjs.org, load the source into the content
store as a Source record, and then create "builds" which move the
package contents to /usr/lib/node_modules/<name>@<version> and symlink
the npm dependencies into the package's node_modules directory.

There is still a good bit left to do to make this useful. Here is an
abbreviated list:

  - export, obvs. In particular, export will need additional logic (and
    information from the recipe) in order to add the top-level
    /usr/lib/node_modules/<name> (no version) symlinks, as well as the
    bin and man symlinks for top-level packages. The <name>@<version>
    directories are created to allow for multiple npm packages to be
    installed at the same time, which happens frequently, but are not
    yet usable in the sense that you need the versionless path for
    'require(<name>)'. The non-standard directories are to avoid the npm
    method of doing things (resolve the entire filesystem tree at
    install time), but will require a few extra steps. What "top-level"
    means also needs to be figured out.

  - Working with the mddb schema a bit better? Everything is in key/val
    data right now instead of using the requirements table. Maybe that
    doesn't matter.

  - Be able to import non-latest versions of packages.

  - Be able to automatically import dependencies instead of bombing out.

2057 of 2541 relevant lines covered (80.95%)

1.59 hits per line

Source Files on job 220.1