/ meteor Public
Stop scanning node_modules directories in PackageSource#_findSources. #9825
Add this suggestion to a batch that can be applied as a single commit. This suggestion is invalid because no changes were made to the code. Suggestions cannot be applied while the pull request is closed. Suggestions cannot be applied while viewing a subset of changes. Only one suggestion per line can be applied in a batch. Add this suggestion to a batch that can be applied as a single commit. Applying suggestions on deleted lines is not supported. You must change the existing code in this line in order to create a valid suggestion. Outdated suggestions cannot be applied. This suggestion has been applied or marked resolved. Suggestions cannot be applied from pending reviews. Suggestions cannot be applied on multi-line comments. Suggestions cannot be applied while the pull request is queued to merge.
This functionality was originally intended to allow importing compiled-to-JS modules from
node_modules, by precompiling any modules found in top-level npm packages, as long as a Meteor compiler plugin was registered for the module's file extension.
As discussed in #9800, this extra compilation burden can be non-trivial, especially if you happen to install an npm package such as
less, which contains hundreds of
.lessfiles in the
More generally, this functionality was an early attempt to enable selective compilation of
node_modulesdirectories, but it was not a good solution to that problem, because in almost all cases the extra compilation was unwanted.
Meteor 1.7 (formerly known as 1.6.2) will give full control over selective compilation of
node_modulesback to the application developer (#9771), which should afford a much better solution to this problem. If you've installed some
.tsfiles from npm into your
node_modulesdirectory, just create a symlink to the package directory within your application, and those modules will be compiled and become importable by other JS modules, as if they were part of the application.