When I package an app for windows using electrify, the npm dependencies have path lengths that exceed the 260 character limit imposed by Windows.
I've tried using "flatten-packages", but still no success.
How can I reduce the path lengths without breaking the app? At this point any solution is welcome - even a manual one.
I found the answer thanks to MasterAM - you need to update both the electrify dependencies and meteor's npm. For posterity, these are the required steps:
1) meteor npm install -g npm#3 (deep dependency problem has been fixed with npm v 3)
2) meteor remove arboleya:electrify
3) npm install -g electrify-updated-test (this is an unofficial updated version of electrify with new dependencies)
4) remove any node_modules folder from your project + .electrify folder
5) meteor update (this updates to 1.3.5.1 - the deep dependency problem has been fixed since 1.3.4)
6) electrify package
Related
Because I use the Netlify CLI tools on travis, I need to have a node version above 8 but the R container I use only has 6.12 according to the error message. I saw that it is possible to specify the node version for java script projects and there is an answer for PHP projects here on StackOverflow, but I tried both and they did not work for my case. What is the proper way of installing a specific node version in an arbitrary travis container such that other applications can access it ? Or maybe even better, (how) can I make npm satisfy the minimal version dependency on node when installing the Netlify CLI tools? I have no prior experience with npm. You can find the version history of my .travis file here.
To install Netlify CLI, make sure you have Node.js version 8 or higher
Based on the docs for Netlify here
Quickest solution for Travis
Optionally, your repository can contain a .nvmrc file in the repository root to specify which single version of Node.js to run your tests against.
The quote from the docs say to add a .nvmrc file to your project at the root with the version
.nvmrc
8.14.0
Note: replace the version with the one compatible with your project that meets all requirements. Also, the .nvmrc file is only read when node_js key in your .travis.yml files does not specify a nodejs version.
Based on the solution provided by #talves, I figured out I can modify the before_script step to install a specific version of node, e.g. 8.14:
before_script:
- nvm install 8.14
- npm install -g netlify-cli
- Rscript -e 'blogdown::install_hugo()'
As nvm and npm were already installed. To install the latest stable release replace 8.14 with node above. That way, I don't need the .nvmrc file.
After upgrading Meteor to 1.3.x version NPM really came to play. But as always there is back side of the coin: build size.
On meteor 1.2.x build size is ~50MB, ~7k files
On meteor 1.3.x build size is ~190MB, ~27k files.
Twenty seven thousand files. That's quite a number. Not to mention path size exceeding 256 (a trouble for windows users).
I've dig into what meteor included into the build and it seems that all the npm_modules is here with all the stuff that is need to build some modules and their dependencies.
The question is: how to build meteor app without unnessesary npm files, leaving only the ones that are actually used by app at runtime?
Update:
On meteor 1.4.1_3 if you create a simple project meteor create dummy-project and go through all the common stuff like npm meteor install and meteor npm prune --production and them make a bundle out of it with meteor build c:\dummy --directory you will get a folder with the same 7k files and almost 2k folders (by the way it will not run node main.js out of the box as you might expect). If you tinker through folders you can find babel compiler inside that takes ~3.5k files.
Why do I need babel compiler inside compiled app?
To gain an introspective of your packages,
npm list --depth 0
to see the current packages in your project with only one level.
Inspect that list, and decide if you don't need a package and uninstall it.
You can also use other flags such as
npm list --depth 1 #the number represents the max depth
npm list --long true #for more information about the packages
npm list --global true #to check your global packages.
npm help-search <searchTerm>
Hope that helps you gain more insight in your packages. help-search Link
You may see that multiple packages depends on the same packages, and then it's up to you to decided what your application needs to run successfully.
Edit 1
You can exclude the packages inside your devDependencies, so that when you're publishing/deploying your code you have a cleaner package.
You do this by using npm prune --production - that removes all your devDependencies, and will require your users to do a npm install for your package to work. For info here
If I'm setting up a project and running npm install -abc xyz, can I run another npm install in another terminal instance, for the same project, whilst this is still running?
Thanks!
You can install multiple packages with a single command like this:
npm install --save package1 package2 package3 ...
EDIT:
Installing packages separately, while theoretically possible, could create problems. When an install command is issued, npm looks up existing modules and downloads missing packages into a staging folder .staging inside node_modules. Once downloaded it copies the packages into the node_modules sub-folder (and removes .staging).
In npm2, modules had their own dependencies stored underneath themselves like this:
node_modules
- dependencyA
- node_modules
- dependencyC
- dependencyB
- node_modules
- dependencyC
Notice how dependency A and B both rely on C. If C is the same version in both cases, it would use twice the space.
In npm3, dependencies are flattened like this:
node_modules
- dependencyA
- dependencyB
- dependencyC
If for some reason an older version is used in a dependency, it follows the npm2 convention for that module.
I'd stick with the intended use of npm and use the multiple install functionality.
I simply use the following
example
npm i daterangepicker select2
I'm using grunt-cli on travis to execute tests. It's installed globally during the install step like this:
install:
# amongst other install steps
- npm list -g grunt-cli --depth=0 || npm install -g grunt-cli
and then I'm caching it, like this, per this question (which, incidentally, I answered):
cache:
directories:
- $(npm config get prefix)/bin/grunt-cli
However, on the next build, I see this: tar: /home/travis/.nvm/v0.10.36/bin/grunt-cli: Not found in archive. And the reason is, grunt-cli gets cached in .nvm/v0.10.40/ because that's what version of node is being tested against (mostly by default - we just have node_js: 0.10 set in the config, so it installs the most recent version). But apparently the starting version of node on travis is 0.10.36. Obviously, there are ways around this, but this seems like extremely naive behavior. I mean, travis does the cache first, then nvm installs the right version of node rendering the initial cache useless. Maybe they just didn't have global node_modules in mind for caching. Is there something I'm missing with configuration? Or should I just npm config set prefix to a version-independent path and add it to my $PATH? (Or alternatively, use a fully qualified version - major.minor.patch - and hard-code the cache directory?)
I just started learning Meteor JS on a fresh copy of OSX. I used the Meteor install instructions to install it. Everything works well - I can install Meteor packages and run the local instance. But where is Node.js and npm? I assume it must be installed with Meteor because everything runs, but the npm and node command is not available. Am I supposed to install Node separately?
Thanks,
Kevin N.
Edit: Corrected npm in the question title which OS X keeps changing to nom.
As of METEOR#1.1.0.2, node and npm are stored in :
/home/username/.meteor/packages/meteor-tool/1.1.3/mt-os.linux.x86_64/dev_bundle/bin/
(The path depends on both the username and architecture of course).
If you're doing only Meteor dev, you won't need node on its own, you might however need npm to install Meteor related tools such as Meteor Up (mup), in which case you need to install npm separately or alias the command to use the Meteor one.