Stop backing up node_modules? 🤔

[rwjblue]

When ember-try's functionality was initially created, the package managers that existed at the time (IIRC it was npm@1 and npm@2) were extremely bad at ensuring the node_modules directory is laid out correctly. It was very very bad at fixing an invalid tree.

Current versions (for quite some time) do not have this issue, and backing up / restoring is quite a long time.

I'd like to remove the backup of node_modules...

Thoughts?

[alexlafroscia]

I would definitely be in favor of this; my one complaint with using ember-try is that it adds a lot of "time" overhead to running the tests. Especially in CI, where you often install all of the normal dependencies, then run ember-try and re-install all the dependencies again with a different ember-source version (and whatever else). In CI, it often doesn't matter if you've re-arranged node_modules since it's the only thing that will use them anyway! Anything that reduces the amount of overhead from this addon would be really welcome.

[mansona]

I noticed something else recently that ember-try doesn't seem to use the package-lock.json at all 🤔 which could also be contributing to the slowdowns

[kategengler]

There's another issue open related to lockfiles, where we may change defaults. But, it very intentionally does not use lockfiles as in the common case of an addon testing against multiple versions of a dep we want other deps to "float" as they would for a new install. This can be overridden and is documented in the README, but I would only recommend for apps and non-public projects that do not expect to be installed in unknown sets of dependencies.

[mansona]

Ah yes I have found the other issue #597 I will respond to your comment over there so as not to pollute this thread 👍