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

Upgrade to 1.3.2.4 from 1.3 has caused very long files.lstat times during compilation #7008

Closed
tomRedox opened this issue May 9, 2016 · 27 comments

Comments

@tomRedox
Copy link

@tomRedox tomRedox commented May 9, 2016

I just merged in some code that includes an update from 1.3 to 1.3.2.4 and my rebuild time has gone from 7s to 48s.

Turning the logging on seems to show the issue is in the compile stage, particularly with files.stat and files.lstat.

| files.readFile 3 ms (3)
| files.exists 5 ms (4)
| Rebuild App..................................................47,749 ms (1)
| ├─ compiler.compile(the app).................................42,790 ms (1)
| │ └─ compileUnibuild (the app)..............................42,790 ms (2)
| │ ├─ files.realpath 2,804 ms (3748)
| │ ├─ files.readdir 4,408 ms (12338)
| │ ├─ files.stat 10,082 ms (69234)
| │ ├─ files.readFile 328 ms (1250)
| │ ├─ files.lstat 18,460 ms (78054)
| │ └─ other compileUnibuild (the app) 6,692 ms
| ├─ bundler.bundle..makeClientTarget...........................3,722 ms (1)

Things I've tried so far, none of which helped:

  • uninstalled and reinstalled Meteor (Windows 8.1)
  • deleted the contents of .meteor/local
  • deleted the contents of node_modules and reinstalled them
  • cleared the npm cache
  • upgrading to 1.3.3 beta
  • deleted everything in AppData\Local.meteor
  • Running the SSD optimizer in Windows

I also tried reverting back to 1.3 (had to delete everything in AppData\Local.meteor to get that to work) and it's quicker, it takes around 25s to reload (so still not the 7s or so it was before). As with 1.3.2.4, the delay in 1.3 seems to be in the compile stage:

| Rebuild App..................................................24,493 ms (1)
| ├─ compiler.compile(the app).................................21,104 ms (1)
| │ └─ compileUnibuild (the app)..............................21,104 ms (2)
| │ ├─ files.readdir 1,549 ms (5032)
| │ ├─ files.lstat 16,265 ms (78054)
| │ └─ other compileUnibuild (the app) 2,942 ms

What's actually happening in the files.lstat stage, what are the variables that would cause this stage to be slow?

@abernix
Copy link
Member

@abernix abernix commented May 9, 2016

Can you provide some information about the number of files in your project? You can right click the various project folders and go to Properties to get a recursive count of files and folders. It would be nice to have information about the size of your entire project folder (including .meteor) and the .meteor folder by itself.

@tomRedox
Copy link
Author

@tomRedox tomRedox commented May 9, 2016

I think the file count is probably the issue, specifically the file count in node_modules by the looks of things.

The actual code files (the ones in import, client and server) are: 192 files, 338KB.
The .meteor dir is: ~2.5k files, 400MB

I deleted the contents of node_modules again and this time re-added the entries to package.json one at a time. There were a lot of unneeded references in there for bits of code that are no longer in use or that were abandoned experiments.

Dependences before the cull: node_modules contained ~30k files, ~135MB (225MB on disk)

 "dependencies": {
    "accounting": "^0.4.1",
    "babel-core": "^6.7.6",
    "babel-preset-es2015": "^6.6.0",
    "babel-preset-react": "^6.5.0",
    "babel-preset-stage-0": "^6.5.0",
    "babel-preset-stage-2": "^6.5.0",
    "classnames": "^2.2.4",
    "externalify": "^0.1.0",
    "history": "^2.0.0",
    "indexof": "0.0.1",
    "moment": "^2.13.0",
    "rc-menu": "^4.11.2",
    "react": "^15.0.2",
    "react-addons-css-transition-group": "^15.0.2",
    "react-addons-pure-render-mixin": "^15.0.2",
    "react-addons-test-utils": "^15.0.2",
    "react-autosuggest": "^3.5.0",
    "react-collapse": "^2.0.0",
    "react-datepicker": "^0.26.0",
    "react-dom": "^15.0.2",
    "react-height": "^2.0.4",
    "react-motion": "^0.4.2",
    "react-mounter": "^1.0.0",
    "react-redux": "^4.4.0",
    "react-router": "^2.0.0-rc6",
    "react-s-alert": "^1.0.3",
    "react-select": "^1.0.0-beta12",
    "react-transform-hmr": "^1.0.4",
    "redux": "^3.3.1",
    "redux-devtools": "^3.1.1",
    "redux-devtools-dock-monitor": "^1.1.0",
    "redux-devtools-log-monitor": "^1.0.5",
    "redux-thunk": "^1.0.3",
    "string-humanize": "^1.0.0",
    "tracker-component": "^1.3.13",
    "velocity-react": "^1.1.3"
  },
  "devDependencies": {
    "babel-plugin-react-transform": "^2.0.2",
    "babel-preset-meteor": "^6.6.6",
    "chai": "^3.5.0",
    "chai-datetime": "^1.4.1",
    "enzyme": "^2.0.0",
    "eslint": "^2.4.0",
    "eslint-config-airbnb": "^6.1.0",
    "eslint-plugin-react": "^4.2.3",
    "faker": "^3.0.1",
    "react-addons-test-utils": "*",
    "react-transform-catch-errors": "^1.0.2",
    "react-transform-hmr": "^1.0.4",
    "redbox-react": "^1.2.2",
    "testdouble": "^1.4.1"
  }

Dependencies now: node_modules contains ~6k files, ~17.5MB (23MB on disk)

  "dependencies": {
    "accounting": "^0.4.1",
    "classnames": "^2.2.5",
    "moment": "^2.13.0",
    "rc-menu": "^4.12.1",
    "react": "^15.0.2",
    "react-addons-css-transition-group": "^15.0.2",
    "react-addons-pure-render-mixin": "^15.0.2",
    "react-datepicker": "^0.27.0",
    "react-dom": "^15.0.2",
    "react-mounter": "^1.2.0",
    "react-redux": "^4.4.0",
    "react-s-alert": "^1.0.3",
    "react-select": "^1.0.0-beta13",
    "redux": "^3.3.1",
    "redux-devtools": "^3.3.1",
    "redux-devtools-dock-monitor": "^1.1.1",
    "redux-devtools-log-monitor": "^1.0.11",
    "redux-thunk": "^1.0.3",
    "string-humanize": "^1.0.0",
    "tracker-component": "^1.3.13",
    "velocity-react": "^1.1.5"
  },
  "devDependencies": {
    "chai": "^3.5.0"
  }

The cull has got the build time for 1.3.2.4 down to ~12.5s and the for 1.3 to ~9s. My gut feeling is Babel might be the main cause of this, checking my colleague's machine all of the babel folders together contain over 10k files.

@tomRedox
Copy link
Author

@tomRedox tomRedox commented May 9, 2016

Adding Babel back in pushed the file count in node_modules up by ~11k to ~17k, and the dir size to ~40MB. Rebuild times in 1.3.2.4 increased to ~19s.

New dev dependencies:

 "devDependencies": {
    "babel-core": "^6.8.0",
    "babel-preset-es2015": "^6.6.0",
    "babel-preset-es2015": "^6.5.0",
    "babel-preset-stage-0": "^6.5.0",
    "babel-preset-stage-2": "^6.5.0",
    "babel-preset-meteor": "^6.6.6",
    "babel-plugin-react-transform": "^2.0.2",
    "chai": "^3.5.0",
    "chai-datetime": "^1.4.1",
    "testdouble": "^1.4.2"
  }
@richard-edwards
Copy link

@richard-edwards richard-edwards commented May 11, 2016

I am also getting big rebuild times for Meteor 1.3.2.4 which make it unworkable as far as productivity goes.

63 second rebuilds on Windows 10 i7/32GB
19 second rebuilds on Mac Mini El Capitan i5/8GB

Here is a gist of both rebuilds, https://gist.github.com/redwards1966/e8818f677c7ba88a60ef2e077d977639

I did an npm prune on both before doing the tests. Both also have virus scanners that don't even look at the source folders.

node_modules is about 82,000 files
meteor folder is about 6,000 files

I'm going to be calling my client today to have to put the project on hold because I'm getting no productivity at all with this setup. I went with the growing pains of 1.3 for a month or so now and just can't keep going with the times this high.

Let me know what I can do to help please.

@tomRedox
Copy link
Author

@tomRedox tomRedox commented May 11, 2016

So the comment here relating to Windows' slow lstat emulation seems like it may be related to this issue: http://superuser.com/a/974456/591942

@menelike
Copy link
Contributor

@menelike menelike commented May 31, 2016

Even running METEOR@1.3.3-beta.1 as recommended in #6750 does not solve this.
We use meteor:webpack as client builds become fast enough to get productivity going on.
Babel and especially it's presets consist of a lot files with a huge size overhead. I think that they should not be considered anywhere in meteor.

7574f74 should fix this, but it seems that somewhere down the rabbit hole it still does not help and a lot of files get touched.

Therefore slow builds are coupled to huge node_modules and devDependencies. We will try to move all babel related dependencies to global, keep you updated.

@menelike
Copy link
Contributor

@menelike menelike commented Jun 3, 2016

tl;dr we move all dev dependencies away from meteor, but make them accessible for webpack and therefore reduce the node_modules overhead

We ended up with a whacky solution to keep productivity going on, read more here

The root of this problem has to be identified, I guess that this causes a lot of trouble for all medium/large sized projects where node_modules starts to grow.

@bevinhex
Copy link

@bevinhex bevinhex commented Jun 13, 2016

I've been trying to implement a continuous deployment environment for two weeks now , and stuck at meteor build.
Why meteor breaks everything since 1.3 !? when first it came out, I had hard time using router with react, waited for months, and now I try it again, it stucks at build.
I wish 1.3 was never came out.

@menelike
Copy link
Contributor

@menelike menelike commented Jun 14, 2016

@bevinhex since we started using meteor we always had to work on the build system, it took us just too much time.

Now we moved away from webpack to Meteor meteor-hmr in combo with Meteor v1.3.3.
This is the first time everything runs smooth, server and client rebuilds are fast, everything works as intended (just HMR has a few bugs, should be fixed / released soon)

One major problem we had was the huge babel deps. Since Meteor 1.3.3 has native babel support we could skip all that and just add our explicit babel plugins. This is our current babel config

{
  "plugins": [
    "react-hot-loader/babel",
    "transform-decorators-legacy",
    "transform-class-properties",
    "transform-export-extensions"
  ]
}

This is the very first time we call Meteor production ready ;)

@kachkaev
Copy link

@kachkaev kachkaev commented Jun 17, 2016

I might be doing something wrong, but I can't get Meteor builds happen reasonably quickly even in rather small projects. This happens both on quite a decent Ubuntu machine and on OSX, not on Windows NT. Adding meteor-hmr partially helps, but it only works for React components and does not even cover changes in Less files. Updating a style or a method on a server has become a real pain – I have noticed that I've started thinking twice before hitting cmd+s or ctrl+s. This was not the case when I just got into the Meteor world this Feb or when I was doing building apps with another framework.

The whole point of live-reloading to me is an opportunity to experiment. With an editor and a browser on two screens, you can do a dozen of small patches to your interface per minute and quickly get all layouts and colours sorted out. A need to wait for 10-20 seconds between padding: 10px and padding: 12px screws up the whole process – you can no longer afford to experiment.

The current project I'm working on does have quite a few folders in node_modules, 421 to be precise. However, most of them are just the dependencies of eslint and remark, which are listed in devDependencies. Only these few guys are to be used inside my Meteor app:

  "dependencies": {
    "classnames": "^2.2.5",
    "font-awesome": "^4.6.3",
    "lodash": "^4.13.1",
    "react": "^15.1.0",
    "react-addons-css-transition-group": "^15.1.0",
    "react-addons-pure-render-mixin": "^15.1.0",
    "react-dom": "^15.1.0",
    "react-fontawesome": "^1.1.0",
    "react-hot-loader": "^3.0.0-beta.2",
    "react-router": "^2.4.1",
    "three": "^0.77.1"
  },

I know I can move linters and a few other devDependencies to globals, but how to share the project in a team then? Should not meteor just be a bit smarter in terms of what modules to grab?

This does not seem like a tasks that's way to complex: meteor can deal with devDependencies by default unless there is some extra parameter in package.json. E.g.:

 "meteorNpmStrategy": {
     "includeDevDependencies": false,
     "whitelist": ["x", "y", "z"] // if some dev dependencies are needed in Meteor (e.g. 4 testing)
}

(some devDependencies might be used in meteor test)

PS: I've been trying meteor npm install, not just npm install since I guessed that that command could contain some whitelisting hack, but it did not help.

PPS: Overall, I do not agree that this issue should have tag feature instead of bug. It is also not just Windows-specific.

@menelike
Copy link
Contributor

@menelike menelike commented Jun 19, 2016

@kachkaev
We did not need the whacky "npm global packages" as described in #7008 (comment) when we moved to Meteor 1.3.3 and HMR. The main reason behind this was the native babel support which was the reason we used meteor webpack before. Without babel devDependencies our node_modules shrunk from 500MB to 220MB (and keep in mind that babel has a lot of small files too).

If you measure build time with METEOR_PROFILE you may notice that builds start to become slower with bigger node_modules footprint. This problem does not depend on production dependencies, it's about node_modules in general. At least this was our observation from a Meteor 1.3+.

Before this a server rebuild took 2-3 (best case) to 5+ minutes.

A need to wait for 10-20 seconds between padding: 10px and padding: 12px screws up the whole process – you can no longer afford to experiment.

imho 10-20 seconds for non HMR client rebuilds is as fast as it can currently get.

PPS: Overall, I do not agree that this issue should have tag feature instead of bug. It is also not just Windows-specific.

Hell yeah.

@benjamn
Copy link
Member

@benjamn benjamn commented Jun 20, 2016

Meteor 1.3.3 no longer bundles devDependencies (see #6750), which will be a big performance improvement if you have a huge node_modules directory with lots of devDependencies. If you're having performance problems with Meteor 1.3-1.3.2.4, you should do everything you can to update to (at least) Meteor 1.3.3.

Better yet, try meteor update --release 1.3.4-rc.0, which uses npm@3 for the first time, so meteor npm install will be much more aggressive about flattening the dependency tree.

@benjamn benjamn added this to the Release 1.3.4 milestone Jun 22, 2016
@benjamn benjamn self-assigned this Jun 22, 2016
@mjmasn
Copy link
Contributor

@mjmasn mjmasn commented Jun 22, 2016

@benjamn Not sure if this is the same issue but I'm getting 20s rebuild time after editing a single line of a template. App startup takes 60 seconds (120 seconds if I run meteor in production mode, and maybe up to 5 minutes for a meteor build). I do appear to have 151064 files in the project (including symlinked imports and packages directories). Not sure what 'normal' is though.

I was already using NPM 3 and before that file count had already removed babel and a load of other npm devDependencies from the imports directory where I was using it for running unit tests outside of meteor. Not sure the rebuild time has changed but it still seems slow. I would expect (need) a 1 line change in a template or style to take no more than 3 seconds to keep in the flow of programming. Waiting 20 seconds is killing my productivity.

I have multiple node_modules directories (the app itself, the imports directory, and one of the modules in the imports directory), would this have any impact?

I'll give 1.3.4-rc.0 a go and report back.

EDIT: BTW this is Meteor 1.3.3.1, laptop spec below:
screen shot 2016-06-22 at 15 54 08

| 
| files.stat                                                        0 ms (6)
| files.readFile                                                   12 ms (4)
| files.writeFileAtomically.......................................911 ms (1)
| └─ files.writeFile                                              911 ms (1)
| Rebuild App..................................................18,783 ms (1)
| ├─ compiler.compile(the app).................................12,563 ms (1)
| │  └─ compileUnibuild (the app)..............................12,562 ms (2)
| │     ├─ files.realpath                                       2,036 ms (7457)
| │     ├─ files.readdir                                        3,122 ms (14993)
| │     ├─ files.stat                                           2,653 ms (194890)
| │     ├─ files.readFile                                         529 ms (2537)
| │     ├─ files.lstat                                            266 ms (2062)
| │     └─ other compileUnibuild (the app)                      3,947 ms
| ├─ bundler.bundle..makeClientTarget...........................5,913 ms (1)
| │  └─ Target#make.............................................5,913 ms (1)
| │     ├─ Target#_runCompilerPlugins...........................1,424 ms (1)
| │     │  ├─ plugin ecmascript.................................1,016 ms (1)
| │     │  │  ├─ files.stat                                       241 ms (3334)
| │     │  │  ├─ Babel.compile                                    423 ms (363)
| │     │  │  └─ other plugin ecmascript                          323 ms
| │     │  └─ plugin templating                                   212 ms (1)
| │     ├─ Target#_emitResources................................3,819 ms (1)
| │     │  ├─ PackageSourceBatch.computeJsOutputFilesMap..........499 ms (1)
| │     │  │  ├─ Resolver#resolve                                 208 ms (1191)
| │     │  │  └─ ImportScanner#_readFile..........................166 ms (439)
| │     │  │     └─ files.readFile                                143 ms (439)
| │     │  └─ PackageSourceBatch#getResources...................3,311 ms (135)
| │     │     └─ PackageSourceBatch#_linkJS.....................3,310 ms (135)
| │     │        ├─ linker.fullLink.............................3,065 ms (1)
| │     │        │  ├─ linker Module#getPrelinkedFiles..........1,202 ms (1)
| │     │        │  │  ├─ linker File#getPrelinkedOutput          446 ms (311)
| │     │        │  │  └─ getPrelinkedFiles toStringWithSourceMap 750 ms (1)
| │     │        │  └─ linker Module#computeAssignedVariables...1,861 ms (1)
| │     │        │     └─ linker File#computeAssignedVariables  1,855 ms (312)
| │     │        └─ other PackageSourceBatch#_linkJS              239 ms
| │     └─ ClientTarget#minifyCss.................................599 ms (1)
| │        └─ mergeCss............................................595 ms (1)
| │           ├─ CssTools.parseCss                                205 ms (52)
| │           └─ composing source maps                            293 ms (1)
| └─ bundler writeTargetToPath....................................300 ms (1)
|    └─ ClientTarget#write........................................299 ms (1)
|       ├─ Builder#write..........................................145 ms (98)
|       │  └─ files.writeFile                                     129 ms (2)
|       └─ other ClientTarget#write                               117 ms
| 
| Top leaves:
| other compileUnibuild (the app)..........................3,947 ms (2)
| files.readdir............................................3,122 ms (14993)
| files.stat...............................................2,992 ms (200434)
| files.realpath...........................................2,106 ms (7550)
| linker File#computeAssignedVariables.....................1,855 ms (312)
| files.writeFile..........................................1,048 ms (5)
| getPrelinkedFiles toStringWithSourceMap....................750 ms (1)
| files.readFile.............................................725 ms (3046)
| linker File#getPrelinkedOutput.............................446 ms (311)
| Babel.compile..............................................423 ms (363)
| other plugin ecmascript....................................323 ms (1)
| composing source maps......................................293 ms (1)
| files.lstat................................................266 ms (2062)
| other PackageSourceBatch#_linkJS...........................239 ms (135)
| CssTools.parseCss..........................................205 ms (52)
| other ClientTarget#write...................................117 ms (1)
| sha1.......................................................104 ms (2436)
| 
| (#4) Total: 19,706 ms (Rebuild App)
| 
=> Client modified -- refreshing
@kachkaev
Copy link

@kachkaev kachkaev commented Jun 22, 2016

@mjmasn I just read about my own pain in your message. There is a chance though that the issue will be fixed in 1.3.4 – see #7218 (comment). Fingers crossed!

UPD: Just saw that this issue added to 1.3.4 milestone!

@mjmasn
Copy link
Contributor

@mjmasn mjmasn commented Jun 22, 2016

@kachkaev good to hear. Have to remind myself that things could be worse - given the apparent issues with Windows lately I can't imagine how painful Meteor development is on a Windows machine with spinning disks right now...

@kachkaev
Copy link

@kachkaev kachkaev commented Jun 22, 2016

@benjamn would it be possible not to scan for changes in any of meteor's node_modules at all? The builder could just calculate some hash based on ls node_modules and version numbers in packages.json and do a proper build (like now) if this hash is different. The reason I'm asking is because I imagine at least two alternative approaches, which seem to me less reliable than this one.

One is always looking into dependencies and ignoring devDependencies. This does not solve the root of the problem, because dependencies can get pretty heavy too. E.g. I'm using meteor-hmr + react-hot-loader, which bring in babel and therefore thousands of files. This heavy module is not the only possible case I'm sure.

Another potential approach is to add some hook to meteor npm install, which would trigger the deep build. I'm not sure this is ideal either, because someone (including myself) may forget to prefix npm install with meteor. This kind of absent-mindedness will cause magic that will be hard to investigate (especially for newcomers).

I'm sure you know better how best to reduce the build times – I just wanted to share my own thoughts to potentially make your decision a bit more informed.

@menelike
Copy link
Contributor

@menelike menelike commented Jun 22, 2016

This is not about how we deal with node_modules in production, it just the footprint of node_modules what causes this. I'try to make a test this weekend, imho just installing a ton of devDependencies (which are not imported/required anywhere) should show the build-time decrease.

@benjamn benjamn mentioned this issue Jun 22, 2016
6 of 6 tasks complete
benjamn added a commit that referenced this issue Jun 22, 2016
Passing a function to files.withCache invokes the function and causes the
results of these four files.* methods to be cached for the duration of the
function invocation.

Part of #7253 and #7008.
benjamn added a commit that referenced this issue Jun 22, 2016
This caching vastly reduces the amount of work _findSources must do when
the server restarts, at the small cost of ignoring new files added within
node_modules subdirectories. Even if you have to restart the server when
you add a file to node_modules (super rare), that's still MUCH better than
waiting for _findSources to rescan the node_modules directory every time
the server restarts.

Part of #7253 and #7008.
@benjamn
Copy link
Member

@benjamn benjamn commented Jun 22, 2016

Please confirm whether server restarts are improved after meteor update --release 1.3.4-rc.2. As soon as this is fixed, I'll release Meteor 1.3.4.

@benjamn
Copy link
Member

@benjamn benjamn commented Jun 22, 2016

Though there's definitely a lot more work to do here, I think we should take it up in Meteor 1.4 now that it's somewhat more tolerable in Meteor 1.3.4.

Closing this now, though I'm definitely not claiming the problem is completely fixed.

@markshust
Copy link

@markshust markshust commented Jun 24, 2016

Dev dependencies are still being installed on meteor build in 1.3.4.

I think it's odd that meteor build looks at the local node_modules directory when bundling. I'm thinking it should really execute a new npm install --production at bundle time instead, so that it only includes non-dev dependencies. Does this make sense? I think this would solve the issue where all dev dependencies are included.

@kachkaev
Copy link

@kachkaev kachkaev commented Jun 24, 2016

@markoshust try npm install --only=prod. This is how it works in the new version of npm introduced in 1.3.4.

@markshust
Copy link

@markshust markshust commented Jun 24, 2016

@kachkaev the npm i --production works just fine, no need to change this. i'm just talking on a meteor build, it should not look at node_modules within app, because that's where local dev happens and dev dependencies are always there. it should execute a npm i --production at bundle time, and look at the results of the node_modules from that output instead.

@benjamn
Copy link
Member

@benjamn benjamn commented Jun 24, 2016

@markoshust I'm curious what behavior you're observing, because the following steps definitely produce the expected result for me:

meteor create dev-deps
cd dev-deps
meteor npm install --save-dev react
meteor build ../dev-deps-build
cd ../dev-deps-build
tar xf dev-deps.tar.gz
# No react here:
ls bundle/programs/server/npm/node_modules
@markshust
Copy link

@markshust markshust commented Jun 24, 2016

@benjamn i'm heading out, but let me try to replicate what i was seeing. i did just switch some things around, it could have been something i was doing that was causing this.

@funston
Copy link

@funston funston commented Jun 29, 2016

i'm on 1.3.4.1 and still burdened by 20 minute build times. is there a clean/simple workaround? If it helps it is hanging on

| (#1) Total: 21,625 ms (ProjectContext prepareProjectForBuild)
|
| (#2) Profiling: Build App
Processing files with ecmascript (for... /

Actually been > 20 minutes now and no indication what it's doing or for how much longer. Project at a standstill. Was working fine before 1.3 upgrade and 1.3.4.1 didn't help

@egaleme
Copy link

@egaleme egaleme commented Jul 14, 2016

i'm using a windows 8 machine and cant seem to update from meteor 1.3.2.4 to meteor 1.3.4.1
how do i do it?

@vladejs
Copy link

@vladejs vladejs commented Sep 21, 2016

Is there a way to avoid meteor build to include node_modules folder so I can manually do npm install after it finishes?

I've noticed in the README.md generated by meteor build command that I have to run npm i to install a few dependencies, while it copied during build time my node_modules into server/npm/ folder.

So what I want to know is, if I delete that /server/npm/node_modules folder. How can I generate it without doing meteor build again?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
14 participants
You can’t perform that action at this time.