Keep bundled /public and /private node_modules symlink content #9666
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Many npm based packages provide supporting assets that need to be made available, when used on the web. For example, to use the `font-awesome` package properly, the `node_modules/font-awesome/fonts` files need to be made accessible to incoming web requests. With Meteor, an easy way to handle this would be to create a symlink to `node_modules/font-awesome/fonts` from within an application's `/public` directory. This would then allow all of `font-awesome`'s font files to be accessed directly by incoming clients. Unfortunately, while this approach does work in development when using the Meteor Tool, it does not work when production bundles are created. Meteor's isobuild process uses a helper class called `SymlinkLoopChecker`, to make sure the build process doesn't get caught up in an infinite loop trying to follow circular symlinks. Currently, a shared `SymlinkLoopChecker` instance is used to watch for symlink loops during both the `_findSoures` and `_findAssets` parts of the isobuild process. `_findSources` is called first, and covers source files that an application uses from the `node_modules` directory. The `SymlinkLoopChecker` tracks all of the `node_modules` directories covered, so they can be watched for in the future (to prevent duplicate inclusions). Next, `_findAssets` is called using the same `SymlinkLoopChecker`. This means that if there are any `node_modules` symlinks used in the `public` or `private` directories, they will be marked as being duplicates (and stripped), since they were already covered in the `_findSources` run. This commit changes things a bit so that both `_findSources` and `_findAssets` use their own `SymlinkLoopChecker` instance. This opens up an applications symlink capabilities a bit, while still preserving some circular symlink safeguards. By doing this, a production application bundle can now maintain the contents of `node_modules` based symlinks, used in `public` and `private`. So in the case of `font-awesome` for example ``` public/fonts --> ../node_modules/font-awesome/fonts ``` becomes the following in the production application bundle ``` bundle/programs/web.browser/app/fonts/[all fonts files] ``` Fixes meteor#7013.
hwillson
changed the title
|
Marking as a work in progress as I'd like to test this a bit more. |
hwillson
changed the title
|
Additional testing done - ready for review! 😅 |
benjamn
approved these changes
Feb 21, 2018
lorensr
pushed a commit
to meteor/guide
that referenced
this pull request
Oct 14, 2018
* Update using-npm-packages.md This adds some documentation for this Issue #7013 PR #9666 that was released in Meteor 1.7. meteor/meteor#9666 * use node_modules consistently use node_modules consistently * Lowercase npm package name
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Suggestion cannot be applied right now. Please check back later.
Many npm based packages provide supporting assets that need to be made available, when used on the web. For example, to use the
font-awesomepackage properly, thenode_modules/font-awesome/fontsfiles need to be made accessible to incoming web requests.With Meteor, an easy way to handle this would be to create a symlink to
node_modules/font-awesome/fontsfrom within an application's/publicdirectory. This would then allow all offont-awesome's font files to be accessed directly by incoming clients. Unfortunately, while this approach does work in development when using the Meteor Tool, it does not work when production bundles are created.Meteor's isobuild process uses a helper class called
SymlinkLoopChecker, to make sure the build process doesn't get caught up in an infinite loop trying to follow circular symlinks. Currently, a sharedSymlinkLoopCheckerinstance is used to watch for symlink loops during both the_findSouresand_findAssetsparts of the isobuild process._findSourcesis called first, and covers source files that an application uses from thenode_modulesdirectory. TheSymlinkLoopCheckertracks all of thenode_modulesdirectories covered, so they can be watched for in the future (to prevent duplicate inclusions). Next,_findAssetsis called using the sameSymlinkLoopChecker. This means that if there are anynode_modulessymlinks used in thepublicorprivatedirectories, they will be marked as being duplicates (and stripped), since they were already covered in the_findSourcesrun.This commit changes things a bit so that both
_findSourcesand_findAssetsuse their ownSymlinkLoopCheckerinstance. This opens up an applications symlink capabilities a bit, while still preserving some circular symlink safeguards. By doing this, a production application bundle can now maintain the contents ofnode_modulesbased symlinks, used inpublicandprivate.So in the case of
font-awesomefor examplebecomes the following in the production application bundle
Fixes #7013.