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’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Native module compilation with io.js 2.x.x #1620

Closed
imyller opened this issue May 5, 2015 · 63 comments
Closed

Native module compilation with io.js 2.x.x #1620

imyller opened this issue May 5, 2015 · 63 comments
Labels
c++ Issues and PRs that require attention from people who are familiar with C++. meta Issues and PRs related to the general management of the project.

Comments

@imyller
Copy link
Member

imyller commented May 5, 2015

I'm opening this issue to track modules needing updates to nan dependency (or something else) for io.js 2.0.0 compatibility.

@mscdex mscdex added the c++ Issues and PRs that require attention from people who are familiar with C++. label May 5, 2015
@BridgeAR
Copy link
Member

BridgeAR commented May 5, 2015

This will be a lot of work... there are a lot of libraries with old nan versions. Just search for a couple of entries.

@Fishrock123 Fishrock123 added the meta Issues and PRs related to the general management of the project. label May 5, 2015
@Fishrock123
Copy link
Contributor

See also / previously: #456

Don't comment here with packages please. Just link to https://github.com/iojs/io.js/issues/1620 when you create the issue on the package's github tracker. :)

@imyller
Copy link
Member Author

imyller commented May 5, 2015

@Fishrock123 good idea.

Just removed original comment and added reference from appropriate pull requests/issues I have openened for this.

@kkoopa
Copy link

kkoopa commented May 5, 2015

Here's a somewhat improved search query.

@targos
Copy link
Member

targos commented May 5, 2015

I am not very used to querying CouchDB but this request seems to give all npm modules that have nan as dependency: https://skimdb.npmjs.com/registry/_design/app/_view/dependentVersions?startkey=[%22nan%22]&endkey=[%22nan!%22]&reduce=false

@imyller
Copy link
Member Author

imyller commented May 5, 2015

This is going to hurt.

@mikeal
Copy link
Contributor

mikeal commented May 5, 2015

We need to find a better way to handle this. As I see it we have two routes:

  • Automate the updating of all these modules in npm/github.
  • Take nan in to core.

@kkoopa
Copy link

kkoopa commented May 5, 2015

Cool, that seems right. It would be awesome if someone were to put together a version-bump bot for minor versions of NAN (unless the package depends on ^1.0, 1.x or *, as those already resolve to latest version in the major). Unfortunately io.js 3.0 will require NAN 2.0, which is going to require rather substantial rewriting. The conversion could still be automated or semi-automated.

@imyller
Copy link
Member Author

imyller commented May 5, 2015

Take nan in to core.

👍

This would be awesome and bring lot of stability to native bindings.

@kkoopa
Copy link

kkoopa commented May 5, 2015

$ wget -qO- 'https://skimdb.npmjs.com/registry/_design/app/_view/dependentVersions?startkey=%5B"nan"%5D&endkey=%5B"nan!"%5D&reduce=false' | tail -n +2 | head -n -1 | egrep -v '1\.8|\^1|1\.x|\*'
{"id":"libetpan","key":["nan","^0.8.0","libetpan"],"value":1},
{"id":"node-glfw","key":["nan","^0.8.0","node-glfw"],"value":1},
{"id":"node-image","key":["nan","^0.8.0","node-image"],"value":1},
{"id":"node-webgl","key":["nan","^0.8.0","node-webgl"],"value":1},
{"id":"polarssl","key":["nan","^0.8.0","polarssl"],"value":1},
{"id":"rdiff","key":["nan","^0.8.0","rdiff"],"value":1},
{"id":"thread-sleep","key":["nan","<2.0.0 >1.6.2 || 1.5.0","thread-sleep"],"value":1},
{"id":"syslogh","key":["nan",">= 1.3.0 < 1.4.0","syslogh"],"value":1},
{"id":"mhash","key":["nan",">= 1.6.2","mhash"],"value":1},
{"id":"number-smusher","key":["nan",">= 1.6.2","number-smusher"],"value":1},
{"id":"rand48","key":["nan",">= 1.6.2","rand48"],"value":1},
{"id":"exiv2","key":["nan",">= 1.7.0","exiv2"],"value":1},
{"id":"neventemitter","key":["nan",">=1.3.0","neventemitter"],"value":1},
{"id":"node-protobuf","key":["nan",">=1.3.0","node-protobuf"],"value":1},
{"id":"navelgazer","key":["nan",">=1.5.0 <1.6.0-0","navelgazer"],"value":1},
{"id":"fidonet-mailer-binkp-crypt","key":["nan",">0.0.0","fidonet-mailer-binkp-crypt"],"value":1},
{"id":"canvas-gurtnec","key":["nan","~0.3.0","canvas-gurtnec"],"value":1},
{"id":"lmdb","key":["nan","~0.3.1","lmdb"],"value":1},
{"id":"max31855pi","key":["nan","~0.3.1","max31855pi"],"value":1},
{"id":"zetta-lmdb","key":["nan","~0.3.1","zetta-lmdb"],"value":1},
{"id":"microtime2","key":["nan","~0.5.1","microtime2"],"value":1},
{"id":"rocksdb","key":["nan","~0.5.2","rocksdb"],"value":1},
{"id":"leveldown-basho","key":["nan","~0.6.0","leveldown-basho"],"value":1},
{"id":"leveldown-hyper","key":["nan","~0.6.0","leveldown-hyper"],"value":1},
{"id":"leveldown-hyper-prebuilt","key":["nan","~0.6.0","leveldown-hyper-prebuilt"],"value":1},
{"id":"lp_solve","key":["nan","~0.6.0","lp_solve"],"value":1},
{"id":"ssh","key":["nan","~0.6.0","ssh"],"value":1},
{"id":"node-stringprep-icu","key":["nan","~0.7.0","node-stringprep-icu"],"value":1},
{"id":"freetype2","key":["nan","~0.8","freetype2"],"value":1},
{"id":"ali.iconv","key":["nan","~0.8.0","ali.iconv"],"value":1},
{"id":"htsengine","key":["nan","~0.8.0","htsengine"],"value":1},
{"id":"inchi","key":["nan","~0.8.0","inchi"],"value":1},
{"id":"mysql-libmysqlclient","key":["nan","~0.8.0","mysql-libmysqlclient"],"value":1},
{"id":"ribs","key":["nan","~0.8.0","ribs"],"value":1},
{"id":"sparkey","key":["nan","~0.8.0","sparkey"],"value":1},
{"id":"sqlite3-trunk","key":["nan","~0.8.0","sqlite3-trunk"],"value":1},
{"id":"ws-non-native","key":["nan","~0.8.0","ws-non-native"],"value":1},
{"id":"canvas-trunk","key":["nan","~1.0.0","canvas-trunk"],"value":1},
{"id":"function-name","key":["nan","~1.0.0","function-name"],"value":1},
{"id":"gitteh","key":["nan","~1.0.0","gitteh"],"value":1},
{"id":"msgpack-bin","key":["nan","~1.0.0","msgpack-bin"],"value":1},
{"id":"nis","key":["nan","~1.0.0","nis"],"value":1},
{"id":"protobuf","key":["nan","~1.0.0","protobuf"],"value":1},
{"id":"pty.js-patch","key":["nan","~1.0.0","pty.js-patch"],"value":1},
{"id":"websocket","key":["nan","~1.0.0","websocket"],"value":1},
{"id":"node-v8-clone","key":["nan","~1.1","node-v8-clone"],"value":1},
{"id":"cjh-hiredis","key":["nan","~1.1.0","cjh-hiredis"],"value":1},
{"id":"durable","key":["nan","~1.1.0","durable"],"value":1},
{"id":"imagemagick-native","key":["nan","~1.1.0","imagemagick-native"],"value":1},
{"id":"procps","key":["nan","~1.1.0","procps"],"value":1},
{"id":"avon","key":["nan","~1.2.0","avon"],"value":1},
{"id":"bbc-xslt","key":["nan","~1.2.0","bbc-xslt"],"value":1},
{"id":"fis-sass-all","key":["nan","~1.2.0","fis-sass-all"],"value":1},
{"id":"goingnative","key":["nan","~1.2.0","goingnative"],"value":1},
{"id":"libxslt","key":["nan","~1.2.0","libxslt"],"value":1},
{"id":"mapbox-glsl-optimizer","key":["nan","~1.2.0","mapbox-glsl-optimizer"],"value":1},
{"id":"memcpy","key":["nan","~1.2.0","memcpy"],"value":1},
{"id":"node-snap7","key":["nan","~1.2.0","node-snap7"],"value":1},
{"id":"node-snappy-linux","key":["nan","~1.2.0","node-snappy-linux"],"value":1},
{"id":"node-snappy-mac","key":["nan","~1.2.0","node-snappy-mac"],"value":1},
{"id":"node-snappy-src","key":["nan","~1.2.0","node-snappy-src"],"value":1},
{"id":"node-snappy-window","key":["nan","~1.2.0","node-snappy-window"],"value":1},
{"id":"node-webcl","key":["nan","~1.2.0","node-webcl"],"value":1},
{"id":"norby","key":["nan","~1.2.0","norby"],"value":1},
{"id":"speaker-prebuild","key":["nan","~1.2.0","speaker-prebuild"],"value":1},
{"id":"v8-flags","key":["nan","~1.2.0","v8-flags"],"value":1},
{"id":"crypt3-prebuilt","key":["nan","~1.3.0","crypt3-prebuilt"],"value":1},
{"id":"font-manager","key":["nan","~1.3.0","font-manager"],"value":1},
{"id":"hmsearch","key":["nan","~1.3.0","hmsearch"],"value":1},
{"id":"lbm","key":["nan","~1.3.0","lbm"],"value":1},
{"id":"lzh","key":["nan","~1.3.0","lzh"],"value":1},
{"id":"magick-compare","key":["nan","~1.3.0","magick-compare"],"value":1},
{"id":"magicklib-native","key":["nan","~1.3.0","magicklib-native"],"value":1},
{"id":"node-ios-device","key":["nan","~1.3.0","node-ios-device"],"value":1},
{"id":"nodegit-probablycorey","key":["nan","~1.3.0","nodegit-probablycorey"],"value":1},
{"id":"osx-tag","key":["nan","~1.3.0","osx-tag"],"value":1},
{"id":"registwin","key":["nan","~1.3.0","registwin"],"value":1},
{"id":"runsync","key":["nan","~1.3.0","runsync"],"value":1},
{"id":"xxhash-nan","key":["nan","~1.3.0","xxhash-nan"],"value":1},
{"id":"boss-mdns","key":["nan","~1.4.0","boss-mdns"],"value":1},
{"id":"reset-usb","key":["nan","~1.4.0","reset-usb"],"value":1},
{"id":"base-convert","key":["nan","~1.4.1","base-convert"],"value":1},
{"id":"bignum-v1113","key":["nan","~1.4.1","bignum-v1113"],"value":1},
{"id":"bot-io","key":["nan","~1.4.1","bot-io"],"value":1},
{"id":"brkontru","key":["nan","~1.4.1","brkontru"],"value":1},
{"id":"flush-all","key":["nan","~1.4.1","flush-all"],"value":1},
{"id":"keepass.io","key":["nan","~1.4.1","keepass.io"],"value":1},
{"id":"lwip","key":["nan","~1.4.1","lwip"],"value":1},
{"id":"xpc-connection-nan","key":["nan","~1.4.1","xpc-connection-nan"],"value":1},
{"id":"fs-ext-prebuilt","key":["nan","~1.4.3","fs-ext-prebuilt"],"value":1},
{"id":"aerospike","key":["nan","~1.5.0","aerospike"],"value":1},
{"id":"contextify","key":["nan","~1.5.0","contextify"],"value":1},
{"id":"hiredis","key":["nan","~1.5.0","hiredis"],"value":1},
{"id":"leveldown-prebuilt","key":["nan","~1.5.0","leveldown-prebuilt"],"value":1},
{"id":"mdns","key":["nan","~1.5.0","mdns"],"value":1},
{"id":"node-kv","key":["nan","~1.5.0","node-kv"],"value":1},
{"id":"node-rijndael","key":["nan","~1.5.0","node-rijndael"],"value":1},
{"id":"zmq","key":["nan","~1.5.0","zmq"],"value":1},
{"id":"canvas","key":["nan","~1.5.1","canvas"],"value":1},
{"id":"dtrace-provider","key":["nan","~1.5.1","dtrace-provider"],"value":1},
{"id":"stall","key":["nan","~1.5.1","stall"],"value":1},
{"id":"zipfile","key":["nan","~1.5.1","zipfile"],"value":1},
{"id":"inotify2","key":["nan","~1.5.3","inotify2"],"value":1},
{"id":"binny","key":["nan","~1.6","binny"],"value":1},
{"id":"fs-ext","key":["nan","~1.6","fs-ext"],"value":1},
{"id":"ip2location-native","key":["nan","~1.6","ip2location-native"],"value":1},
{"id":"murmurhash-native","key":["nan","~1.6","murmurhash-native"],"value":1},
{"id":"zstd","key":["nan","~1.6","zstd"],"value":1},
{"id":"hiredis-simple","key":["nan","~1.6.0","hiredis-simple"],"value":1},
{"id":"midi","key":["nan","~1.6.0","midi"],"value":1},
{"id":"pg-sync","key":["nan","~1.6.0","pg-sync"],"value":1},
{"id":"nodejieba","key":["nan","~1.6.1","nodejieba"],"value":1},
{"id":"pcap","key":["nan","~1.6.1","pcap"],"value":1},
{"id":"r-pi-gpio","key":["nan","~1.6.1","r-pi-gpio"],"value":1},
{"id":"sypexgeo-vyvid","key":["nan","~1.6.1","sypexgeo-vyvid"],"value":1},
{"id":"bignum","key":["nan","~1.6.2","bignum"],"value":1},
{"id":"celt","key":["nan","~1.6.2","celt"],"value":1},
{"id":"epoll","key":["nan","~1.6.2","epoll"],"value":1},
{"id":"geoip","key":["nan","~1.6.2","geoip"],"value":1},
{"id":"groove","key":["nan","~1.6.2","groove"],"value":1},
{"id":"http-sync","key":["nan","~1.6.2","http-sync"],"value":1},
{"id":"iojs-nanomsg","key":["nan","~1.6.2","iojs-nanomsg"],"value":1},
{"id":"jitterbuffer","key":["nan","~1.6.2","jitterbuffer"],"value":1},
{"id":"murmurhash3","key":["nan","~1.6.2","murmurhash3"],"value":1},
{"id":"node-espeak","key":["nan","~1.6.2","node-espeak"],"value":1},
{"id":"node-opus","key":["nan","~1.6.2","node-opus"],"value":1},
{"id":"node-samplerate","key":["nan","~1.6.2","node-samplerate"],"value":1},
{"id":"node-svm","key":["nan","~1.6.2","node-svm"],"value":1},
{"id":"nosql-leveldb","key":["nan","~1.6.2","nosql-leveldb"],"value":1},
{"id":"osrm","key":["nan","~1.6.2","osrm"],"value":1},
{"id":"r-pi-usonic","key":["nan","~1.6.2","r-pi-usonic"],"value":1},
{"id":"req-sync","key":["nan","~1.6.2","req-sync"],"value":1},
{"id":"unqlite","key":["nan","~1.6.2","unqlite"],"value":1},
{"id":"weak","key":["nan","~1.6.2","weak"],"value":1},
{"id":"winiputils","key":["nan","~1.6.2","winiputils"],"value":1},
{"id":"wtf8","key":["nan","~1.6.2","wtf8"],"value":1},
{"id":"protagonist","key":["nan","~1.6.x","protagonist"],"value":1},
{"id":"protagonist-experimental","key":["nan","~1.6.x","protagonist-experimental"],"value":1},
{"id":"freetype2_render","key":["nan","~1.7","freetype2_render"],"value":1},
{"id":"abstract-socket","key":["nan","~1.7.0","abstract-socket"],"value":1},
{"id":"arc4random","key":["nan","~1.7.0","arc4random"],"value":1},
{"id":"ashot","key":["nan","~1.7.0","ashot"],"value":1},
{"id":"base91","key":["nan","~1.7.0","base91"],"value":1},
{"id":"chacha-native","key":["nan","~1.7.0","chacha-native"],"value":1},
{"id":"couchbase","key":["nan","~1.7.0","couchbase"],"value":1},
{"id":"fast-feed","key":["nan","~1.7.0","fast-feed"],"value":1},
{"id":"ffi-atom-shell","key":["nan","~1.7.0","ffi-atom-shell"],"value":1},
{"id":"flat-lame","key":["nan","~1.7.0","flat-lame"],"value":1},
{"id":"i2c-bus","key":["nan","~1.7.0","i2c-bus"],"value":1},
{"id":"jumpsuit","key":["nan","~1.7.0","jumpsuit"],"value":1},
{"id":"kdtree","key":["nan","~1.7.0","kdtree"],"value":1},
{"id":"libxl","key":["nan","~1.7.0","libxl"],"value":1},
{"id":"lwip-decoder","key":["nan","~1.7.0","lwip-decoder"],"value":1},
{"id":"lwip-encoder","key":["nan","~1.7.0","lwip-encoder"],"value":1},
{"id":"lwip-image","key":["nan","~1.7.0","lwip-image"],"value":1},
{"id":"lzma-native","key":["nan","~1.7.0","lzma-native"],"value":1},
{"id":"mac-key-press","key":["nan","~1.7.0","mac-key-press"],"value":1},
{"id":"mapnik","key":["nan","~1.7.0","mapnik"],"value":1},
{"id":"nanomsg","key":["nan","~1.7.0","nanomsg"],"value":1},
{"id":"nbind","key":["nan","~1.7.0","nbind"],"value":1},
{"id":"node-expat","key":["nan","~1.7.0","node-expat"],"value":1},
{"id":"node-lwip","key":["nan","~1.7.0","node-lwip"],"value":1},
{"id":"node-mpg123-util","key":["nan","~1.7.0","node-mpg123-util"],"value":1},
{"id":"oniguruma","key":["nan","~1.7.0","oniguruma"],"value":1},
{"id":"ref","key":["nan","~1.7.0","ref"],"value":1},
{"id":"speaker","key":["nan","~1.7.0","speaker"],"value":1},
{"id":"srs","key":["nan","~1.7.0","srs"],"value":1},
{"id":"strong-oracle","key":["nan","~1.7.0","strong-oracle"],"value":1},
{"id":"time","key":["nan","~1.7.0","time"],"value":1},
{"id":"traceview-bindings","key":["nan","~1.7.0","traceview-bindings"],"value":1},
{"id":"udev","key":["nan","~1.7.0","udev"],"value":1},
{"id":"wrtc","key":["nan","~1.7.0","wrtc"],"value":1},
{"id":"sophia","key":["nan","0.4.x","sophia"],"value":1},
{"id":"pty.js-11","key":["nan","0.7.0","pty.js-11"],"value":1},
{"id":"custom-object","key":["nan","0.8.0","custom-object"],"value":1},
{"id":"phash-image","key":["nan","1","phash-image"],"value":1},
{"id":"crypt3","key":["nan","1 >=1.6.2","crypt3"],"value":1},
{"id":"dlopen","key":["nan","1.0.0","dlopen"],"value":1},
{"id":"nan-example-eol","key":["nan","1.0.0","nan-example-eol"],"value":1},
{"id":"tov8","key":["nan","1.0.0","tov8"],"value":1},
{"id":"authenticate-pam","key":["nan","1.1.0","authenticate-pam"],"value":1},
{"id":"kytea","key":["nan","1.1.0","kytea"],"value":1},
{"id":"cbind","key":["nan","1.1.2","cbind"],"value":1},
{"id":"parse-x509","key":["nan","1.1.2","parse-x509"],"value":1},
{"id":"java2","key":["nan","1.2.0","java2"],"value":1},
{"id":"mathematical","key":["nan","1.2.0","mathematical"],"value":1},
{"id":"meteor-pathwatcher-tweaks","key":["nan","1.2.0","meteor-pathwatcher-tweaks"],"value":1},
{"id":"crc32c","key":["nan","1.2.x","crc32c"],"value":1},
{"id":"bitcoind.js","key":["nan","1.3.0","bitcoind.js"],"value":1},
{"id":"icu-numformat","key":["nan","1.3.0","icu-numformat"],"value":1},
{"id":"lzf","key":["nan","1.3.0","lzf"],"value":1},
{"id":"node-minizip","key":["nan","1.3.0","node-minizip"],"value":1},
{"id":"s2","key":["nan","1.3.0","s2"],"value":1},
{"id":"ucoin","key":["nan","1.3.0","ucoin"],"value":1},
{"id":"tree-sitter-javascript","key":["nan","1.3.x","tree-sitter-javascript"],"value":1},
{"id":"carmen-cache","key":["nan","1.4.1","carmen-cache"],"value":1},
{"id":"opencv","key":["nan","1.4.3","opencv"],"value":1},
{"id":"raspi-core","key":["nan","1.4.x","raspi-core"],"value":1},
{"id":"native-hashset","key":["nan","1.5.0","native-hashset"],"value":1},
{"id":"node-zoom","key":["nan","1.5.1","node-zoom"],"value":1},
{"id":"bluetooth-serial-port","key":["nan","1.5.x","bluetooth-serial-port"],"value":1},
{"id":"hashring","key":["nan","1.5.x","hashring"],"value":1},
{"id":"bunyan-syslog","key":["nan","1.6.2","bunyan-syslog"],"value":1},
{"id":"gdal","key":["nan","1.6.2","gdal"],"value":1},
{"id":"iconv-x64","key":["nan","1.6.2","iconv-x64"],"value":1},
{"id":"node-ping-addon","key":["nan","1.6.2","node-ping-addon"],"value":1},
{"id":"node-pingit","key":["nan","1.6.2","node-pingit"],"value":1},
{"id":"oid","key":["nan","1.6.2","oid"],"value":1},
{"id":"raspi","key":["nan","1.6.x","raspi"],"value":1},
{"id":"raspi-gpio","key":["nan","1.6.x","raspi-gpio"],"value":1},
{"id":"raspi-pwm","key":["nan","1.6.x","raspi-pwm"],"value":1},
{"id":"webworker-threads","key":["nan","1.6.x","webworker-threads"],"value":1},
{"id":"bcrypt","key":["nan","1.7.0","bcrypt"],"value":1},
{"id":"ccap","key":["nan","1.7.0","ccap"],"value":1},
{"id":"cloudcv-bootstrap","key":["nan","1.7.0","cloudcv-bootstrap"],"value":1},
{"id":"dlfcn","key":["nan","1.7.0","dlfcn"],"value":1},
{"id":"java","key":["nan","1.7.0","java"],"value":1},
{"id":"libxmljs","key":["nan","1.7.0","libxmljs"],"value":1},
{"id":"pty.js","key":["nan","1.7.0","pty.js"],"value":1},
{"id":"serialport","key":["nan","1.7.0","serialport"],"value":1},
{"id":"snappy","key":["nan","1.7.0","snappy"],"value":1},
{"id":"ttyutil","key":["nan","1.7.0","ttyutil"],"value":1},
{"id":"xml-selector","key":["nan","1.7.0","xml-selector"],"value":1},
{"id":"node-libcurl","key":["nan","1.7.x","node-libcurl"],"value":1},
{"id":"tree-sitter","key":["nan","1.7.x","tree-sitter"],"value":1},
{"id":"tree-sitter-c","key":["nan","1.7.x","tree-sitter-c"],"value":1},
{"id":"tree-sitter-compiler","key":["nan","1.7.x","tree-sitter-compiler"],"value":1},
{"id":"tree-sitter-golang","key":["nan","1.7.x","tree-sitter-golang"],"value":1},
{"id":"sqlite3-atom-shell","key":["nan","git+https://github.com/iojs/nan#155f1d31352d08a3ec9ac206383a670f25428ab7","sqlite3-atom-shell"],"value":1},
{"id":"hdt","key":["nan","git+https://github.com/rvagg/nan.git#master","hdt"],"value":1},
{"id":"cld-atom-shell","key":["nan","https://atom.io/download/atom-shell/nan-1.6.1.tgz","cld-atom-shell"],"value":1},
{"id":"ctags","key":["nan","https://atom.io/download/atom-shell/nan-1.6.1.tgz","ctags"],"value":1},
{"id":"ffi-atomshell-paulcbetts","key":["nan","https://atom.io/download/atom-shell/nan-1.6.1.tgz","ffi-atomshell-paulcbetts"],"value":1},
{"id":"git-utils","key":["nan","https://atom.io/download/atom-shell/nan-1.6.1.tgz","git-utils"],"value":1},
{"id":"keyboard-layout","key":["nan","https://atom.io/download/atom-shell/nan-1.6.1.tgz","keyboard-layout"],"value":1},
{"id":"keytar","key":["nan","https://atom.io/download/atom-shell/nan-1.6.1.tgz","keytar"],"value":1},
{"id":"nslog","key":["nan","https://atom.io/download/atom-shell/nan-1.6.1.tgz","nslog"],"value":1},
{"id":"opencv-atom-shell","key":["nan","https://atom.io/download/atom-shell/nan-1.6.1.tgz","opencv-atom-shell"],"value":1},
{"id":"pathwatcher","key":["nan","https://atom.io/download/atom-shell/nan-1.6.1.tgz","pathwatcher"],"value":1},
{"id":"ref-atom-shell","key":["nan","https://atom.io/download/atom-shell/nan-1.6.1.tgz","ref-atom-shell"],"value":1},
{"id":"runas","key":["nan","https://atom.io/download/atom-shell/nan-1.6.1.tgz","runas"],"value":1},
{"id":"scrollbar-style","key":["nan","https://atom.io/download/atom-shell/nan-1.6.1.tgz","scrollbar-style"],"value":1},
{"id":"spellchecker","key":["nan","https://atom.io/download/atom-shell/nan-1.6.1.tgz","spellchecker"],"value":1}

@bnoordhuis
Copy link
Member

Take nan in to core.

I can think of many reasons why that will end up introducing more breakage down the road than it fixes.

Someone (and I'm not volunteering) should come up with a detailed proposal how to implement that and be prepared for some serious hole shooting.

@rvagg
Copy link
Member

rvagg commented May 5, 2015

another option .. which I've resisted and actively recommended against, is getting packages to use ^ in their nan dependency definition, those that use this range should work just fine because we're still in 1.x. I'm hessitant to do this because of my deep distaste and distrust of such a liberal range but it would deal with this particular problem

@Qard
Copy link
Member

Qard commented May 5, 2015

The whole point of nan is more liberal support of node/io.js versions, so it makes sense to me that the dependency would have a more liberal range.

@kkoopa
Copy link

kkoopa commented May 5, 2015

That crow's foot (the circumflex) is not nice, no. But it was more of a problem in the past. Since NAN 1.0, there has been hardly any backwards incompatibilities. If the versioning were any stricter, it would just lead to every release being a major release and it would be back to square one.

Still, it's impossible to test every native module on every single configuration. Sometimes stuff breaks due to oversight. It is usually fixed within 24 hours, but still causes the reverse problem temporarily: Packages break through no fault of their own with no changes to them. It is a double-edged sword.

@imyller
Copy link
Member Author

imyller commented May 5, 2015

Meanwhile.. I'm just testing and serial-pull-requesting every package dependency that breaks in our stack with io.js 2.0.0 with more recent nan.

Native bindings are important. Whatever core can do to improve the situation in future versions helps.

@rvagg
Copy link
Member

rvagg commented May 5, 2015

The breakage that came with NanNew is precisely the reason I advocate against ^. When developing our libraries we like to think that internal changes don't have an impact on the external API but we never have extensive enough tests to be sure that it won't break for some novel (and often non-novel) use-case that exists in the wild. This happens regularly across all kinds of libraries and by using ^ for dependencies you're throwing caution to the wind and pretending that the developers of your dependencies are perfect in their ability to keep external breakage at 0%, but that's fantasy-land because people are involved and you know what people are like.

@lygstate
Copy link

In fact, my computer already installed both vs 2013 and vs 2010, but its choose vs 2010 by default somehow.

@sam-github
Copy link
Contributor

#1620 (comment)

I'm not understanding nan's use of semver at all. Could someone enlighten me.

As far as I can tell, this churn was completely unnecessary and could have been avoided two ways:

  1. Using ^ semver. Even people who don't trust their dependent authors to not screw up and break their code with a minor release (but do trust them not to break their code with a patch release? That's a weird form of paranoia.) would hopefully trust the nan authors to get it right.

@rvagg Every one of the many , many packages using nan that were updated in this PR seem to be using non-caret dep specs. This is at your urging? And you are comfortable re-urging all of them to update again to the next nan minor, ad nauseum? This seems to be trading off a possible introduction of a breaking change in nan done in a minor release, hopefully low probability, against an absolutely guaranteed break for every user of nan when io.js or v8 eventually requires it. That's a poor bet.

  1. I only checked a half-dozen at random, but I didn't find a single one that made an actual code change, just the package change. So, whatever changes were needed to support io.js 2.x were clearly implementable as a semver patch - they did not require using any new nan features. Why was a 1.7.1 of nan not released that supported 2.x, thus avoiding all this churn, even for people with-semi-pinned dependencies on nan?

The purpose of nan, I thought, was not having to modify my packages when there are changes to io.js/v8, but that doesn't seem to have been achieved.

What am I missing? Why was this necessary?

@kkoopa
Copy link

kkoopa commented May 24, 2015

Because a V8 function exposed through Nan lost support for a certain extra argument, and the wrapping Nan function had ti remove this as well. It was a rarely used feature, so I figured it would not create too much problems by releasing a minor. Strict semver would have required a major version bump for that change. Then there were some API additions with new wrappers that became necessary.

On May 24, 2015 7:24:19 PM EEST, Sam Roberts notifications@github.com wrote:

#1620 (comment)

I'm not understanding nan's use of semver at all. Could someone
enlighten me.

As far as I can tell, this churn was completely unnecessary and could
have been avoided two ways:

  1. Using ^ semver. Even people who don't trust their dependent
    authors to not screw up and break their code with a minor release (but
    do trust them not to break their code with a patch release? That's a
    weird form of paranoia.) would hopefully trust the nan authors to get
    it right.

@rvagg Every one of the many , many packages using nan that were
updated in this PR seem to be using non-caret dep specs. This is at
your urging? And you are comfortable re-urging all of them to update
again to the next nan minor, ad nauseum? This seems to be trading off a
possible introduction of a breaking change in nan done in a minor
release, hopefully low probability, against an absolutely guaranteed
break for every user of nan when io.js or v8 eventually requires it.
That's a poor bet.

  1. I only checked a half-dozen at random, but I didn't find a single
    one that made an actual code change, just the package change. So,
    whatever changes were needed to support io.js 2.x were clearly
    implementable as a semver patch - they did not require using any new
    nan features. Why was a 1.7.1 of nan not released that supported 2.x,
    thus avoiding all this churn, even for people with-semi-pinned
    dependencies on nan?

The purpose of nan, I thought, was not having to modify my packages
when there are changes to io.js/v8, but that doesn't seem to have been
achieved.

What am I missing? Why was this necessary?


Reply to this email directly or view it on GitHub:
#1620 (comment)

@kkoopa
Copy link

kkoopa commented May 24, 2015

Autodetection defaults to 2010, yes. You need to explicitly specify msvs_version=2013 to gyp.

On May 24, 2015 5:56:43 PM EEST, Yonggang Luo notifications@github.com wrote:

In fact, my computer already installed both vs 2013 and vs 2010, but
its choose vs 2010 by default somehow.


Reply to this email directly or view it on GitHub:
#1620 (comment)

@sam-github
Copy link
Contributor

I figured it would not create too much problems by releasing a minor.

I would agree with you about that. semver is no panacea, and that might have been a good judgement call.

Except it wasn't, because nan apparently recommends pinning deps to MINORS instead of allowing them to float within a MAJOR, everyone following nan's advice had to update their package.

If you have to update a package, who cares if you update from 1.6.x -> 1.7.x, or from 1.x -> 2.x? Its the same one-character change across dozens and dozens of repos.

If people were using ^, they wouldn't have noticed your change. If you updated the major, the same number of people who were effected by the minor bump would have noticed the change.

So you now have all the disadvantages of semver and none of the advantages.

@kkoopa
Copy link

kkoopa commented May 24, 2015

Yes, you may be right. The recommendation of pinning to minors originated before the ^-notation had become available, and since then we have gradually adopted a stricter adherence to semver.

We try to keep backwards compatibility across versions, but sometimes mistakes happen. There have been around two or three occasions where in the last year where a new minor of NAN has unintentionally broken some configurations. This typically results in bug reports within an hour of release. It is usually fixed within a day or so, but builds breaking because of this can be very confusing to unexpecting users.

Most packages depend on NAN indirectly through the dependency chain, over 40 % of all the packages in npm, so any bugs affect a lot of packages.

So, while the intention is that users should be able to pin to majors of NAN, there may be temporary issues with large impact across the ecosystem when doing this.

Sometimes we release minors just to add more APIs or rewrite the internals of existing ones to fix bugs or improve performance. These are often not strictly necessary for functionality for every addon. These can be avoided by pinning to minors.

On May 24, 2015 10:07:10 PM EEST, Sam Roberts notifications@github.com wrote:

I figured it would not create too much problems by releasing a minor.

I would agree with you about that. semver is no panacea, and that might
have been a good judgement call.

Except it wasn't, because nan apparently recommends pinning deps to
MINORS instead of allowing them to float within a MAJOR, everyone
following nan's advice had to update their package.

If you have to update a package, who cares if you update from 1.6.x -> 1.7.x, or from 1.x -> 2.x? Its the same one-character change across
dozens and dozens of repos.

If people were using ^, they wouldn't have noticed your change. If
you updated the major, the same number of people who were effected by
the minor bump would have noticed the change.

So you now have all the disadvantages of semver and none of the
advantages.


Reply to this email directly or view it on GitHub:
#1620 (comment)

@sam-github
Copy link
Contributor

So, while the intention is that users should be able to pin to majors of NAN, there may be temporary issues with large impact across the ecosystem when doing this.

Mistakes happen, but if nan releases a breaking change in a minor by accident, as you say, there will be bug reports pretty quickly, and nan can make things right with a single publish, and everything will work again. No big deal, nan is pretty diligent, as you say, they/you fix these things quite quickly.

When an update to io.js requires a minor update to nan, there are more than temporary issues, as volunteers need to work through the entire set of minor-pinned packages. As you say, binary addons tend to be buried deep, so its even hard for people to fix themselves without forking all the intermediary deps. Its a bit frustrating that the issues can't be solved quickly by nan, we have to wait for the ecosystem to catch up.

Anyhow, its a bit late. My random sampling of the merges that mention this PR found that they are all minor pinned.

But the next time nan bumps a minor to get io.js compatibility again, as is sure to happen, please consider asking people up to use the ^, so nan itself can fix the addon ecosystem in the future without this kind of churn. At least until V8 changes something so important that nan can't paper over it with its current macros, and nan users really will have to rewrite some of their bindings. That's out of all of our control, though.

@rvagg
Copy link
Member

rvagg commented May 25, 2015 via email

@DamonOehlman
Copy link

👍 @rvagg

I will admit that I've taken to bumping major versions not just when making a "breaking change", but also when I feel that something that has changed under the hood and represents enough risk that it needs to be an intentional change by a package consumer.

It does feel a bit strange, but with the --save syntax using the ^ specifier by default I don't think I have much other choice. I think while the original intent of moving to the hat syntax for --save operations was to highlight the importance of using the major version component of our packages, it has had a side effect that does need to be addressed.

@imyller
Copy link
Member Author

imyller commented May 25, 2015

👍 to @rvagg

However, I still strongly suggest that package authors should be given opportunity to migrate to newer NAN well before ABI breaking core changes are publicly released.

In this case I hope to see NAN 2.x.x well before core hits 3.x.x.

@kkoopa
Copy link

kkoopa commented May 25, 2015

That will likely not happen. io.js 3.0 will probably be released within a week or two. NAN 2.0 will be released soon after that. There is, however, a 'next' branch available that builds with io.js next. It will become 2.0, but is not finalized or frozen yet. It aims at working with V8 4.5, which is the current development branch, so that there won't be unnecesary, avoidable, breakage.

All 500+ packages will need rewriting and updating. This will not happen overnight. I'm considering writing a simple migration script, like 2to3.py, which should take care of some changes automatically. But, it will take some time to write and will not cover everything. If someone were to put this together, I'd gladly accept a PR.

On May 25, 2015 9:14:05 AM EEST, Ilkka Myller notifications@github.com wrote:

👍 to @rvagg

However, I still strongly suggest that package authors should be given
opportunity to migrate to newer NAN well before ABI breaking core
changes are publicly released.

In this case I hope to see NAN 2.x.x well before core hits 3.x.x.


Reply to this email directly or view it on GitHub:
#1620 (comment)

@RnbWd
Copy link

RnbWd commented May 25, 2015

If npm packages were integrated with Travis CI or something similar, we'd have more accurate information about the build status of packages, which might be useful in general, especially for in this situation.

@imyller
Copy link
Member Author

imyller commented May 25, 2015

@RnbWd Excellent idea.

Many packages are already individually testing with Travis CI pulling from GitHub, but more general automated testing done straight from npm repository against available Node/io.js versions would be an awesome service. It could easily show compatibility statistics against any core version. I think running simple npm install (and npm test only if enabled by package author) would be enough.

I think someone is already working on this ;) If not, then someone should.

@defunctzombie
Copy link
Contributor

@DamonOehlman

Add this to your .npmrc

save-exact=true

Now every --save will use exact versions. I think there is an equivalent for ~ but I don't remember it.

@RnbWd
Copy link

RnbWd commented May 25, 2015

@defunctzombie definitely agree! I use that setting as well. You can use npm config ls -l to show all defaults, so changing to ~ would be changing save-prefix = "~", although save-exact probably overrides save-prefix . cmdline:

npm set save-prefix '~'    
or
npm set save-exact true

edit: is there any benefit using save-prefix="~"?

@DamonOehlman
Copy link

@defunctzombie @RnbWd thanks - sounds like a plan :)

@brendanashworth
Copy link
Contributor

3.0.0 has been released, so I'll close this one for now. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
c++ Issues and PRs that require attention from people who are familiar with C++. meta Issues and PRs related to the general management of the project.
Projects
None yet
Development

No branches or pull requests