We Keep Coding

Specifing a jQuery version for Meteor twbs:bootstrap

After installing Meteor via Chocolatey on windows 10, and meteor add twbs:bootstrap This Meteor app gives a barowser error
Uncaught Error: Bootstrap's JavaScript requires jQuery version 1.9.1 or higher, but lower than version 3
So which version am I running now?
meteor list did not produce any jquery related lines.
./meteor/versions file has a line saying "jquery#1.11.11"
But didn't meteor create already install a jQuery as per the web site? "This package is automatically included in every new Meteor app by meteor create."
DO I need to run meteor add jquery? but I remember doing that already at least once. and "jquery": "^3.5.1" is under dependencies in packages.json and package-lock.json
The command: meteor show jquery shows package: jquery#3.0.0
Please help untangle this. Thanks
Solved:
meteor remove twbs:bootstrap
npm install bootstrap
Added "popper.js":"^1.16.0" to dependencies in package.json

There is a difference between the Meteor package version jquery#3.0.0 and the npm version `"jquery": "^3.5.1".
The Meteor package jquery#3.0.0 allows to override deprecated jQuery versions (for example delivered as direct dependency of an old Meteor package) with the jQuery version, installed via npm.
./meteor/versions file has a line saying "jquery#1.11.11"
Note, that just adding jquery#3.0.0 sometimes fails (when packages require direct dependencies). Then you have to change in your .meteor/packages the entry jquery#3.0.0 to jquery#3.0.0!
However, this may still cause the mentioned error, because your jQuery will be a version > 3 (because your project will then use the npm jQuery 3.5.1).
What are your options then to resolve the error:
a) Install npm jquery > 1 and < 3
b) Install the latest jQuery and use Bootstrap 4 via npm
option a
The first option would basically require you to run meteor npm install --save jquery#2.2.4 to get the latest jQuery < 3.
This could be a fast solution, if your app will be used internally (for example in a corporate intranet or smth.) but would be a big problem if out in the wild. There are plenty of vulnerabilities that have been detected since 3.5.1 and you should think about, whether this will be an issue or not.
option b
The better way is to also use the latest bootstrap an jQuery from the beginning and use their npm packages. It is a bit more of work than just adding twbs:bootstrap but it gives you the flexibility and maintainability that you need:
install the latest npm packages
$ meteor remove twbs:botstrap
$ meteor npm install --save jquery#latest bootstrap popper.js
edit the Meteor jquery package
Open .meteor/packages in your editor of choice and change:
jquery#3.0.0 to jquery#3.0.0!
import the packages
In your startup routine, for example in client/main.js you do the following:
import 'bootstrap'
import 'bootstrap/dist/css/bootstrap.css' // default theme
import popper from 'popper.js'
global.Popper = global.Popper || popper
(optional) import a custom theme
If you want to apply your own theme, your may also install the scss toolchain:
$ meteor remove standard-minifier-css
$ meteor add fourseven:scss seba:minifiers-autoprefixer
and then import your custom theme instead of the standard css:
import 'bootstrap'
import popper from 'popper.js'
import './theme.scss'
global.Popper = global.Popper || popper
to apply your own theme, you need to have theme.scss to follow the structure below:
/* import the necessary Bootstrap files */
#import "{}/node_modules/bootstrap/scss/functions";
#import "{}/node_modules/bootstrap/scss/variables";
#import "{}/node_modules/bootstrap/scss/mixins/buttons";
/* these are just examples, if your theme overrides more you need to import the respective files */
/* -------begin customization-------- */
/* here your custom theme variables, colors etc. */
/* ------- end customization -------- */
/* finally, import Bootstrap to set the changes! */
#import "{}/node_modules/bootstrap/scss/bootstrap.scss";
I know this might be too much of an answer but in the long run I highly suggest you to omit the deprecated BS3 and go for a more flexible strategy, as shown in option b here.

Problems using "index.js" to import ES6 JS Modules

I'm working with React Native and using index.js to manage modules. I have many projects consuming from the same components folder, which has a structure like this:
components
|_ComponentOne.js
|_ComponentTwo.js
|_index.js
In which the index.js looks like this:
export * from './ComponentOne.js';
export * from './ComponentTwo.js';
Now lets say I have three projects:
ProjectOne, which uses ComponentOne;
ProjectTwo, which uses ComponentTwo;
ProjectThree, which uses both;
Every project has its own files, but they refer to this same folder to use components (like a shared assets folder). Everything works fine while all the projects have all dependencies for all components.
In another words, I have a problem when one of the projects doesn't install a dependency for one of the components, even when the project doesn't uses that component.
Let's take as an example ProjectOne, which uses only ComponentOne. If ComponentTwo (which is not used in this project) has dependency X, I have to npm install dependency X even on ProjectOne, or an error is given. Again, ProjectOne doesn't use dependency X.
I can only image this happens because the index.js validates all declared exports, even when they're not used.
I'm trying to find an alternative to not be forced to install plugins and other things that I won't even use in my projects. I know that if I remove the index.js and start importing files directly on projects, it will work, but I would like to keep the index.js structure (to be able to use multi import syntax import { ComponentOne, ComponentTwo } from 'components').
Any suggestion?
Update:
The error I get, when I do not npm install dependency X is
Module `X` does not exist in the Haste module map
If I install it, everything works.
I'm using the terminal to install the application directly into an android phone. The JS bundle is automatically created by Metro (RN default).

Webpack / NPM: Use build version of installed module instead of re-building from source

I would like to use the dat.GUI library for a project that's build with Webpack 2. If I install the module via npm -install --save-dev dat.gui and then try to import it using import * as DAT from 'dat.gui'; I get the following error when Webpack is trying to compile my project:
ERROR in ./~/dat.gui/src/dat/controllers/NumberControllerSlider.js
Module not found: Error: Can't resolve 'style' in
'/home/me/myProject/node_modules/dat.gui/src/dat/controllers'
BREAKING CHANGE: It's no longer allowed to omit the '-loader' suffix
when using loaders.
I know this error occurs when using Webpack 2 to build Webpack 1 based projects. But why is Webpack even trying to build the module if there already is a build version inside node_modules/dat.gui/build';? Is there a way to tell Webpack or NPM to use the existing build version without trying to re-build it?

When importing a node module, webpack looks into its package.json and uses the main field as entry of the module, similar to what Node.js does (webpack looks for more fields by default, see resolve.mainFields).
Since for dat.gui the main field does not point to the built version but to the source, which actually inlines loaders as seen in dat.gui#0.6.1 - NumberControllerSlider.js for the styleSheet import, and that is not a good idea in general and certainly not to publish.
But you can import the built version by specifying the corresponding path. So your import would be:
import * as DAT from 'dat.gui/build/dat.gui.js';
If you'd like to still import just dat.gui you can configure resolve.alias to point to the built version as follows:
resolve: {
alias: {
'dat.gui': 'dat.gui/build/dat.gui.js'
}
}
With that you can use your original import statement:
import * as DAT from 'dat.gui';

Which npm packages will and will not work on Angular 2? How do I tell?

Does an NPM package need to be modified to be compatible with Angular 2 (eg. add in typings, make directives for them) or will any existing package work? If they're not all compatible, how do I know what is and what is not compatible?
For example, say I want to import this package (https://github.com/pvorb/node-md5). I'm aware there is a ts-md5 package for angular 2 to do md5 - I'm just using this package as an example.
How would I get this to work?
I've installed it using
npm install md5 --save
npm install #types/md5 --save
but I can't seem to be import it
import {md5} from 'md5';
I get this error message after I try to run
Module
'"/Users/xxx/Source/tempProjects/ngUnderscore/node_modules/#types/md5/index"'
resolves to a non-module entity and cannot be imported using this
construct.
I'm not sure what this message means. Does it mean that in its current state, the package is not compatible or am I trying to use the package incorrectly?

I managed to make it work using declare and require instead of import (import won't work for this non-module lib)
declare const require: any;
const md5 = require('md5');
If you don't want to workaround import like this, you can try using Typescript MD5 implementation called ts-md5. Then import like the one below should work. (referenced from this question)
import { Md5 } from 'ts-md5/dist/md5'
If there is no TS implementation, you can search for the types in DefinitelyTyped and then simply install package by npm i --save-dev #types/{package-name}

If the library works on your project depends on many factors: your Angular version, your TypeScript version, etc.
This said, is obvious that we should check the library's documentation and see which dependencies has and its versions, and of course the library should be the Angular 2 version of itself. Following your example, there are several md5 libraries but if you use TypeScript you should maybe consider this one: https://www.npmjs.com/package/ts-md5
If we have all that covered but still there is something not working because of some type of incompatibility, like for example:
My version of angular is 2, the library I just installed works with Angular 4. I have code full of <template>, library uses <ng-template>... What can I do?
You can fork the library in github and modify whatever you need to asure it is compatible with your project. Steps:
Fork library repository and modify what you need
Subscribe to main library repository in order to be updated with changes
In packages.json use your forked version of the library, for example:
"ng2-datetime": "https://github.com/my_user/ng2-datetime/tarball/my_forked_version_name",
If you think that your modifications could suit other users... Make a Pull request! :D

This is more of a TypeScript question since md5 is not an Angular package.
The key is to get the import correct to be equivalent to a require() function.
import * as md5 from "md5";
Use directly in TypeScript file:
console.log(md5('message'));
To use this on the template, preferably it should be used in method implementation, but can also be exposed directly. Add it as a property on the Component:
md5: any = md5;
Then on the template:
{{md5('message')}}

They usually say which Angular it is meant for, sometimes you have one package for both or for each.
If you are using an Angular 1x package and there is no Angular2 compatibility, then you can just use ngUpgrade.
But If you are using a common plugin then there must be an angular 2 solution.
If you want the other way around then you're probably going the wrong way.

The issue you experienced is not related to Angular. It is an existing issue on TypeScript when importing CommonJS packages.
The rule of thumb (my recommendation) is to stay away from using the interop feature (i.e. import * as X from 'x') when importing CommonJS and use the "old" syntax instead (i.e. import X = require('x')).
When CommonJS is exporting a function in the form of module.exports = function() {...}, import * as X from 'x' does not work.
This includes the case when the package is exporting an ES6 class but transpiling to ES5 with Babel.
You may see some packages do work with this syntax, but that is because the typings have a hack in it:
declare module 'x' {
function foo(): void
namespace foo {} // <-- the hack
exports = foo
}
There are other reasons the interop is not a good idea, including the syntax between TypeScript (import * X from 'x') and Babel (import X from 'x') does not agree.
You can learn more about it here and follow the links:
https://github.com/unional/typescript-guidelines/blob/master/pages/default/modules.md#import-keyword
UPDATE: with TypeScript#2.7 released, you can now do import EditableElement from 'Transformer' directly.
Turn on esModuleInterop in your tsconfig.json

Bower install two version of angular at same time

I need to install angular 1.3.18 and 1.4.5 version of angular using bower in same project.Since some part of my code using angular 1.3.18 and some of its dependecy are also using 1.3.18, same case for other version as well.
If I am using only one version some part of code will get broken.
If I use below method
"dependencies": {
"angular": "1.4.5",
"angular": "1.3.18"
}
it is working fine ,After I minify and uglify the code for production only one version of angular is available and some part of code is broken.
Please suggest me a solution for this..

Just modify your bower.json as follows:
{
"dependencies": {
"angular": "~1.4.5",
"another_angular": "angular#1.3.18"
}
}
The another_angular package is now available in another_angular folder in your bower_components.
Note: The key another_angular can be changed at will (in the limits of an acceptable property name in JSON!), but beware that the destination folder will change accordingly.

While angular is not designed to have multiple versions running in the same window (they both assign to window.angular), it is possible using the hack described here:
Multiple versions of AngularJS in one page
The minification issue you are experiencing is most likely due to both versions of angular being assigned to the same global variable, window.angular, and your minifier is over-riding one assignment of that variable (for 1.3.18) with the other (for 1.4.5).