jspm / npm Goto Github PK

Example case is - System.import('npm:unexpected').

We'd need a parse tree to check if the Buffer global object is accessed, and if so, to then add an effective require('buffer').

This probably applies to other globals, although I'm unsure of which ones offhand.

This is because npm calls the version '1.4.3', but the download link retains the old version format.

Fixing this involves a separate request at download time to check for any of this kind of stuff.

While jspm does version selection, we should still obey npm's latest tag for picking the latest version.

An example is jspm install npm:famous where latest is less than the greatest semver match.

Then it can be removed from SystemJS builder.

This would be good to avoid jspm link processing this folder.

The github endpoint supports finding dependencies in bower.json, but the npm endpoint doesn't. It would be nice if these two endpoints were more in line with each other. Possibly even share a lot of the same base codebase?

This caused this confusion: angular/angular#944

Hi! I'm trying to install koa.js on node.js 0.12.0 via jspm. But import statement throws an error:

    file:---/jspm_packages/npm/[email protected]/browser.js:12
    storage = window.localStorage;
    ^
    ReferenceError: window is not defined
    at Object.<anonymous> (file:---/jspm_packages/npm/[email protected]/browser.js:12:13)
    at file:---/jspm_packages/npm/[email protected]/browser.js:62:4
    at Object.exports.runInThisContext (vm.js:74:17)
    at doEval (---/node_modules/jspm/node_modules/systemjs/dist/system.src.js:2308:10)
    at __eval (---/node_modules/jspm/node_modules/systemjs/dist/system.src.js:2222:7)
    at Loader.exec [as __exec] (---/node_modules/jspm/node_modules/systemjs/dist/system.src.js:335:5)
    at load.metadata.execute (---/node_modules/jspm/node_modules/systemjs/dist/system.src.js:1159:16)
    at linkDynamicModule (---/node_modules/jspm/node_modules/systemjs/dist/system.src.js:667:32)
    at getModule (---/node_modules/jspm/node_modules/systemjs/dist/system.src.js:636:9)
    at ---/node_modules/jspm/node_modules/systemjs/dist/system.src.js:671:16

I've tracked down this problem to package.json of debug.js module. There is "browser" field(pointing to browser.js file) which AFAIU jspm-npm treats as a replacement for main entry point and hance systemjs tries to load browser-specific code in node environment. I'm very new to jspm and really not sure where this bug report would be more appropriate(or is this even a bug).

Modules can import a directory by name, which results in the index being loaded from that directory. We should detect these require forms within the local package and convert them into the index reference.

This involves an extra step on build to find all directories in the project and writing a main entry point for them by the same name, if such a file doesn't already exist.

This is due to a require('module') core lib call. We need to configure module as a Node core lib.

Fix the stream module which currently doesn't work due to circular references.

Make these use the node core libs when run on the server - https://github.com/jspm/npm/blob/master/npm.js#L19

Unnecessarily adds Buffer and process as dependencies.

When installing npm:leaflet the build hook seems to stall for some reason.

I've traced this down to this line not returning - https://github.com/jspm/npm/blob/master/npm.js#L318.

This makes me think it is a graceful-fs issue, but it would require isolating the use of graceful-fs through the projects as graceful-fs mutates the fs module.

If a directories.lib is provided in a jspm property in the package.json or in an override, we should still support it. Just the base-level directories.lib should be ignored.

To allow JSON loading to work across packages, it could be worth creating a js entry point for JSON files that loads the JSON file with the plugin.

Specifically -

            format: 'cjs',
            normalize: function(name) {
              if (name.substr(name.length - 3, 3) == '.js')
                return name.substr(0, name.length - 3);
              return name;
            }

We should be able to use the npm resolver at https://github.com/jspm/npm/blob/master/npm.js#L598 to work out it should be a json file and include the json loader plugin accordingly, just like for require('x.json').

This is actual cause of jspm/jspm-cli#556:

In package.json of downloaded module I have aliased dependency:

{
  "b": "npm:b_@^1.3.0"
}

But parseDependencies thinking this is version -> name@version match.

Seems like this if-chain should be fixed to support such dependencies.

This needs to be investigated for feasibility.

I tried to use superagent as is from npm.
Currently it supports browserify via "browser" tag
But instead of specifying a separate main for browser it has this:

"main": "./lib/node/index.js",
"browser": {
  "./lib/node/index.js": "./lib/client.js",
  "emitter": "component-emitter",
  "reduce": "reduce-component"
}

The jspm generated loader [email protected] file points to './lib/node/index.js', so it doesn't work.
And judging from the installed packages, jspm still takes the dependencies from "dependencies" and doesn't follow "browser".
Is it possible to support packages with these kind of settings?

Currently I fork the project and add jspm dependencies under the "jspm" tag.

I wonder how well this will work?

The hard part about this is modularizing the nodelibs package into fully-separated packages for each node core lib, and conditionally including them in dependencies. May well be possible now if the direct browserify repos can be supported without needing any adjustments.

When executing jspm install npm:cloudant somewhere in the process I get the error
err Error: EISDIR, read

Only in Node.

So that we don't inadvertently flatten npm dependencies incorrectly.

http://t.co/LqRO2DGR7R

From jspm/jspm-cli#556.

If we install a package here that has a dependencies: { p: 'jspm:p' } or something like that (jspm endpoint style), we should throw a useful descriptive error message from within this npm endpoint so the user knows how to correct their dependencies (as it will break down the line in the install process anyway).

https://npm.jspm.io/scribe-plugin-toolbar.js

Any ideas why this might be?

The way to handle this is to rather to analyze directory requires first, then perform the rewriting phase directly using this table, instead of going through forwarding modules.

It looks like a require statement is needed on https://github.com/jspm/npm/blob/master/npm.js#L223

Apparently this is supported in npm:

<=0.13.0-rcx

We should add this to the conversion.

//cc @Bubblyworld

If the Node package has a main which is a directory, add the index.js part.

Effectively all dependencies in jspm are peer dependencies, so we just treat them as additional dependencies.

It's just another line like in https://github.com/jspm/npm/blob/master/npm.js#L311.

This is dependent on comprehensive conditional loading support.

It would be awesome if this could read the .npmrc config file for authentication options and use them if necessary to authenticate to the registry.

I am trying to configure it for use with a private npm registry that uses the npm options

always-auth=true`
ca=-----BEGIN CERTIFICATE-----...
_auth=<token>

Adding crypto makes nodelibs a 10 package install, which can easily be seen as overkill for a simple app, and detracts from the configuration simplicity for model cases, which is important to keep.

Ideally we could detect specific node core libs, and only include them when they are used. Then instead of having a single nodelibs repo, we download the nodelibs repos we need as we need them.

The reason this isn't currently supported is because dependencies are returned from getPackageConfig, which is before download completion, and download dependencies are ignored.

The addition would be to allow the build function to return further dependencies. This is the simplest fix and most sensible one.

This happens for npm:omniscient installing react<0.12 to version 0.12 exactly.

As people are moving away from Bower it is becoming more and more common to place browser distribution files into npm.

I disagree with this in principle, but it's happening.

We should run the usual detection process on Node modules, and if that isn't sufficient, manually override in the fixes. I think it will be sufficient for most cases though.

And if they fail, get credentials again.

Depends on endpoint work at jspm/jspm-cli#424