We are using trackjs.com code to help us detect javascript errors. We want the trackjs code to report all errors in any javascript code. This requires that the trackjs code be loaded first.
I know it goes against the general meteor loading order, however we don't want any javascript issues hidden, no matter where the errors are.
We tried including the trackjs.com code included in the compatibility folder and hardcoded in a <head> block. Both of these approaches resulted in the code being loaded last.
Suggestions?
Taken from official documentation:
Files in subdirectories are loaded before files in parent directories, so that files in the deepest subdirectory are loaded first, and files in the root directory are loaded last.
Within a directory, files are loaded in alphabetical order by filename.
After sorting as described above, all files under directories named lib are moved before everything else (preserving their order).
Finally, all files that match main.* are moved after everything else (preserving their order).
So you should be placing them in the lib directory. If you place it in server/lib it is going to be available to the server, or in client/lib the client only. But if you place it in a common lib folder, then it is going to be available to both the client and the server.
That being said, it is usually a better idea to place such code into its own package. Packages have better loading order management as described in the relevant section of the docs.
Finally, you might also want to look at http://observatoryjs.com/ which targets to achieve a similar solution as trackjs and it has native meteor packages you can search and add from http://atmosphere.meteor.com
UPDATE:
These solutions place trackjs after meteor's native code and before yours and any other 3rd party's.
To be able to truly inject trackjs before everything else, there may be a few ways:
https://github.com/arunoda/meteor-fast-render/blob/master/lib/server/inject.js#L52 is how fast-render package alters the contents of head to inject arbitrary scripts. You can inject trackjs at the very beginning using this technique.
You can directly hack https://github.com/meteor/meteor/blob/devel/packages/webapp/webapp_server.js how meteor serves the app. This would again be client side only and prone to meteor update conflicts.
Related
I'm an old COBOL programmer that has self-taught myself web development over the last decade. I've always used asp.net for developing and when I first started out I had no clue what I was doing. There are some cases I still don't :). That brings me to my question. When I first started out I didn't know what Nuget packages were so if I wanted to use something like bootstrap I would would download the files from the bootstrap website and load them into my project in a Scripts folder. To call the files I added them into the bundling function provided by asp.net. I've since discovered Nuget Manager and keep my bootstrap versions updated through it, but I've always been afraid to remove the reference to these files from the bundling package.
Today I'm trying to upgrade bootstrap from 4.6 to 5.1, but I'm getting an error. If I go into my bundling package and comment out the reference to bootstrap my error goes away. So my question is, if I'm using Nuget to manage my packages, is it safe to remove them from the bundling package? I feel like the answer is "yes it's safe" but was hoping for confirmation and maybe an explanation on how and if Nuget and bundling work together, if at all...
Well, nuget simple in "most" cases downloads some .net .dll's and assemblies, and then often sets a reference for you. (you could do this manual, but hey its a whole lot less work).
but, when you use nuget to install those packages, some might include javaScript libries and code (such as your example).
Because the bundling expects the scripts to be say in this location:
Public Shared Sub RegisterBundles(ByVal bundles As BundleCollection)
bundles.Add(New ScriptBundle("~/bundles/WebFormsJs").Include(
"~/Scripts/WebForms/WebForms.js",
"~/Scripts/WebForms/WebUIValidation.js",
"~/Scripts/WebForms/MenuStandards.js",
etc. etc. etc.c
Then of course, when you nuget a package, then the location of the scripts VERY LIKLEY is not going to be the above location.
So, you would then remove your older scripts (and above script referances), and add in the new location of such scripts.
So, you are free to remove the existing bundling references, but you not then enjoy use of the script manager and system to "merge together" the many script files.
So, you don't have to use bundeling anyway.
However, in most cases, you WANT BOTH the SomeJava.js and SomeJava.min.js files to exist. And if you modify those files, then YOU need to regenerate the .min version. Since you not (likely) to be modifying those .js files, then you can well dump the bundling of such files. But you are free also to add them to the above bundling reference.
All bundling does is "merge" the .js files together - so that you don't have 50 or 100 different separate .js files, and thus 50 or 100 difference downloads and references in a web page to use all those many .js files.
So, it not a huge deal. If you only adding say bootstrap via nuget, then I would hunt down the location of the new .js files, and add them to the bundling. But, it not all that huge of a deal if you don't. The issue then becomes how do you add the new .js and .css files to the given web page you are working on. (and toss in use of a master page, and again more complex).
So, in theory, you could remove the existing (older .js references) and then add the css. files that nuget created. I not looked, and don't know if the .js files remain in "packages" folder, or during an install that nuget copies to some folder (such as scirpts).
Just keep in mind, do keep and have the .min versions of those .js files. if you in web.config set debug=false, then the web site flips over to using the .min versions of the .js files - they have to exist, and even without bundling they have to exist, and this "flip" occurs (you now using .min versions of js files).
This is a HUGE topic, and probably oh so far beyond that of a simple post on SO.
but, suffice to say, you can well dump use of the bundling, and remove your older .js references. (but, since you having to do that, then might as well add the newer references then at that point in time, right???).
I try to find and also to delete all the unused libraries in a project. For example I have a folder lib/ with lot of other folder which are the famous libraries. I want to know how I can identify which libraries are not used.
I asked the same question here but the only response I received suggests to me to check each file one by one ...
Can you help me?
I don't think that is possible, as some libraries may be lazy loaded depending on some internal state of your application.
So even if you could somehow find all strong typed references inspecting the code, you have no way of finding out if a library is loaded via magic methods, custom class loaders, dynamically generated include or require statement, eval-ed code and so on.
Without having tests with 95%+ coverage for your non-library code, it is very risky to remove anything from your lib folder. You code may appear to run fine, but still fail in some edge cases.
There's an open source project that can help you to do that:
https://github.com/composer-unused/composer-unused
Installation
composer require composer-unused/composer-unused-plugin
Usage
composer unused
And if you want to use it inside phpstorm, you can look at their composer documentation: https://www.jetbrains.com/help/phpstorm/using-the-composer-dependency-manager.html#create-and-run-composer-scripts
Can I use a styles.css file uploaded on GitHub as styles for multiple projects? I'm trying to define a default style for my projects here: https://raw.githubusercontent.com/GhitaB/default-design/master/styles.css
I prefer to link this file instead of copying it in multiple projects.
RawGit serves raw files directly from GitHub with proper Content-Type headers.
Or, consider using Github Pages
Here we need to distinguish between duplication of code and resources. What you don't want is copying code, because those files would diverge and you'd need to repeat every change for all of them. Having one file uploaded to multiple servers, however, shouldn't be a problem as long as you have one place to edit them all at once.
For this case there's Git submodules. The idea is basically having a repository with the shared part and then including that repository in a specified path in your other projects. You can read more about it here: https://git-scm.com/book/en/v2/Git-Tools-Submodules
This way all your IDE-based and external tools will still work and your website can be deployed as a whole. If, at some point in the future, you decide to have separate CSS files, you can simply replace the submodule with a file and you won't need to change the paths in HTML.
Of course, you can also use the same exact resource in multiple projects simply by pointing them to the same URI, but then the uncoupling might be harder afterwards and you can't see the file in your IDE.
Tl;dr : Is there an equivalent in meteor to .gitignore?
Yes, I am aware of using a leading '.' in the directory name to get meteor to exclude it. But using leading dot is not a solution in this case. Read below to understand.
Longer:
I would like to use Bower.io to install various browser plugins.
Ideally, I run bower in the client subdirectory. Bower does its thing creating the bower_components directory and pulls down the plugin (pick a random jquery plugin for example).
Many plugins include example html, demo css files, etc. to show how to use the plugin.
Unfortunately, Meteor wants to include all that stuff in the application. Which unsurprisingly causes problems.
My current solution is to have bower.io run in the project's parent directory. This is not ideal as I have to copy js/css files over from the bower directory to the meteor client directory. (yes, I could use soft links but then the files would be missing when pushing to production).
With only a few client plugins / css packages this is becoming quite annoying.
NOTE: Renaming files/directories retrieved by bower.io to have a leading '.' or using bower in a dotted subdirectory helps only marginally. I would then have to manually include the files needed.
Is this possibly a duplicate of How to exclude directories/files from Meteor's bundler?
If you want to define the way you name your files, you could try including a certain regex to match in the meteor bundler. Otherwise, maybe it's something that needs to be implemented on a framework level.
I also found this tutorial by Tri on integrating meteor and bower: http://tridnguyen.com/articles/meteor-and-bower/. Tri defines a new meteor package to specify the exact files required on the client.
The best solution, however, is move away from Bower as Meteor offers its own package manager at a framework level. Including the front end files that you need using Meteor packages would be the more productive solution in the long run, especially as the framework changes.
I noticed that Eclipse (Flex Builder) generates hundreds of metadata files. Should I check them into my source control? They seem necessary, because if I delete them Flex Builder just opens up an empty workbench...
Some of these files plainly do not belong in source control (like .history files and some cache files). If I delete them my project opens up again without a hitch. But the list is long and there seem to be no clear separation between folders that contain files that belong in source control and those that do not.
I can't just shove them all into svn, even if I were to ignore the inefficiency, because Eclipse generates new ones constantly, with different names, which in turn also seem to be crucial for the project to load.
Can someone please enlighten me?
Don't check in the hundreds of metadata files. If you want to be able to check out the project in a way that it can just be imported, then check in:
.actionScriptProperties
.project
.flexProperties
And "html-template" and "libs". As Christian says, any resources you depend on. I usually keep those as separate Flex Library projects though.
I generally put all of my source code under src, and I check in src and all of its descendents. If my project relies on any external dependencies (e.g., the Cairngorm SWC, as3corelib, etc.), Flash/graphical assets, stylesheets, or resource files, I check those in, too. But I don't check in any generated (bin-*), intermediate or IDE-specific stuff, because having that stuff in source control doesn't seem to provide much practical benefit, and in my experience has only caused me headaches; in general, I check in the most minimal set of whatever I'd need -- given a clean FlexBuilder installation (or none at all -- for example, if I were compiling instead with mxmlc or compc) and an empty project -- to build the project successfully.
Most of the eclipse project files, like .project, .properties, everything in .settings, can go into your source control. As long as the files don't have user-dependent settings like file paths or local urls, you should be fine.
One method we use is creating local property files that don't get used in SCM, but are included in the ones that do. I.E an ant build file including a local.properties file which has local metadata.
What if the .actionScriptProperties, .project, or .flexProperties have user-dependent stuff in them? Typically this will be url or path information. What's the best practice way of externalizing this? I tried creating path variables, but this only works obviously for paths. Not for things like hostname, etc.