OHDSI Home | Forums | Wiki | Github

Npn build on latest Atlas code gives: ENOENT: no such file or directory, open '/usr/local/tomcat/webapps/atlas/node_modules/qs/dist/qs.js'

While running a npn build on the latest Atlas code, I see the following errors:

wget https://github.com/OHDSI/Atlas/archive/released.zip
RUN npm run build

atlas@2.8.0 build /usr/local/tomcat/webapps/atlas
npm run prep && npm run build:dev

atlas@2.8.0 prep /usr/local/tomcat/webapps/atlas
npm i && npm run clean && npm run genversion

atlas@2.8.0 build:dev /usr/local/tomcat/webapps/atlas
node build/optimize.js && npm run compress

{ Error: Error: ENOENT: no such file or directory, open ‘/usr/local/tomcat/webapps/atlas/node_modules/qs/dist/qs.js’
In module tree:
main
pages/Router

at Object.openSync (fs.js:448:3)

at /usr/local/tomcat/webapps/atlas/node_modules/requirejs/bin/r.js:28332:19
at /usr/local/tomcat/webapps/atlas/node_modules/requirejs/bin/r.js:3059:39
at /usr/local/tomcat/webapps/atlas/node_modules/requirejs/bin/r.js:2999:25
at Function.prim.nextTick (/usr/local/tomcat/webapps/atlas/node_modules/requirejs/bin/r.js:28083:9)
at Object.errback (/usr/local/tomcat/webapps/atlas/node_modules/requirejs/bin/r.js:2998:26)
at Object.callback (/usr/local/tomcat/webapps/atlas/node_modules/requirejs/bin/r.js:2984:23)
at Object.then (/usr/local/tomcat/webapps/atlas/node_modules/requirejs/bin/r.js:3038:23)
at build (/usr/local/tomcat/webapps/atlas/node_modules/requirejs/bin/r.js:28289:12)
at runBuild (/usr/local/tomcat/webapps/atlas/node_modules/requirejs/bin/r.js:30302:17)
at Object.execCb (/usr/local/tomcat/webapps/atlas/node_modules/requirejs/bin/r.js:1946:33)

originalError:
{ Error: ENOENT: no such file or directory, open ‘/usr/local/tomcat/webapps/atlas/node_modules/qs/dist/qs.js’
at Object.openSync (fs.js:448:3)
at Object.readFileSync (fs.js:348:35)
at Object.readFile (/usr/local/tomcat/webapps/atlas/node_modules/requirejs/bin/r.js:3658:27)
at Object.readFileAsync (/usr/local/tomcat/webapps/atlas/node_modules/requirejs/bin/r.js:3672:32)
at Function.require._cacheReadAsync (/usr/local/tomcat/webapps/atlas/node_modules/requirejs/bin/r.js:28102:25)
at /usr/local/tomcat/webapps/atlas/node_modules/requirejs/bin/r.js:27671:48
at /usr/local/tomcat/webapps/atlas/node_modules/requirejs/bin/r.js:3041:37
at /usr/local/tomcat/webapps/atlas/node_modules/requirejs/bin/r.js:2989:25
at Function.prim.nextTick (/usr/local/tomcat/webapps/atlas/node_modules/requirejs/bin/r.js:28083:9)
at Object.callback (/usr/local/tomcat/webapps/atlas/node_modules/requirejs/bin/r.js:2988:26)
errno: -2,
syscall: ‘open’,
code: ‘ENOENT’,
path: ‘/usr/local/tomcat/webapps/atlas/node_modules/qs/dist/qs.js’,
fileName: ‘/usr/local/tomcat/webapps/atlas/node_modules/qs/dist/qs.js’,
moduleTree: [ ‘pages/Router’, ‘main’ ] } }
npm ERR! code ELIFECYCLE

Did you try npm install first?

Hi @Chris_Knoll,
Yes, I did.

If you download the zip file from here: https://github.com/OHDSI/Atlas/archive/v2.8.0.zip

unzip it and just do a npm run build, the issue can be reproduced.

Thanks for you time…

Ok I do see the error, I’m not sure what is causing it yet, but I can reproduce it.

Ok, the qs dependency broke semver contentions and removed the /dist folder from the output in a later version of the library. In the package.json file in Atlas root, you can modify the following line:

    "qs": "^6.5.2",

to:

    "qs": "6.5.2",

The latter will force a specific version of the QS library. The former allowed 6.9.5 to be installed (because the ^ operator allowed minor version increases) but 6.9.5 breaks the output compared to 6.5.2).

After you make that change, you can run npm build again.

Edit:
I just looked closer at the qs release, and just 5 hours ago they released 6.9.5 (which broke compared to 6.9.4), so I think they may push a fix to this (for 6.9.6) and if that’s the case, you just can wait until they do before you run the npm build. If not, you an make the change above but instead specify 6.9.4 in the version.

The QS developers quickly responded and fixed the mistake, so, if you invoke npm run build again, it should get v6.9.5 of the dependency which hast the output folders.

Hi @Chris_Knoll,
Thanks for quickly following up.

6.9.5 is still having issues. I will use your workaround to use 6.9.4 and see how it goes.

Thanks,

t