search

jspm / npm

NPM Location Service
19 stars 34 forks source link

debug.js bug #45

Closed SF-300 closed 9 years ago

SF-300 commented 9 years ago

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/debug@2.1.1/browser.js:12
    storage = window.localStorage;
    ^
    ReferenceError: window is not defined
    at Object.<anonymous> (file:---/jspm_packages/npm/debug@2.1.1/browser.js:12:13)
    at file:---/jspm_packages/npm/debug@2.1.1/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).

guybedford commented 9 years ago

@SF-300 yes Node support for jspm is currently limited. I wouldn't suggest using jspm for server-side projects just yet, only simple isomorphic use cases.

gobengo commented 9 years ago

Hmm. I ran into this too.

Looks like when jspm/npm downloads the npm:debug package, it looks in the package json and rewrites .main to be debug's package.json .browser string. It stores this int he jspm package cache.

It appears that jspm run and jspm bundle both use that rewritten .main value (always pointing to the 'browser' value).

@guybedford Am I on the right track? What if jspm/npm didn't rewrite main to be the browser value, and then deferred when it decides which path to use as main until a time when it can determine the proper context (e.g. jspm bundle vs jspm run).

I think one of these places would be appropriate, but I couldn't quite figure it out:

I did comment out the lines rewriting 'main' to not use '.browser', and I was able to successfully jspm run a simple script that does import debug from 'debug/debug'. But I couldn't figure out where jspm bundle figures out which entrypoint to use as .main, so I could apply an is-browser heuristic there.

guybedford commented 9 years ago

Yes this is currently a limitation in jspm - it always rewrite to the browser version, and that is why we say that support on the server is limited.

The fix for this is to use conditional environment loading, which will be a feature in the next version of SystemJS. For now though I would suggest sticking with npm on the server for these kinds of libraries. Working on the support this side.