I'd like to use Supergroup.js in ember-cli (I use ember-cli:0.2.7 and ember 1.12.1). Supergroup is implemented as an Underscore or LoDash mixin, so author suggests to include lodash dependency first.
After adding dependencies to bower.json:
//bower.json
"dependencies": {
//...
"lodash": "^3.9.3",
"supergroup":"1.0.13"
}
I got error:
Could not find module lodash
// at supergroup.js: "_ = require('lodash');"
As a workaround I forked supergroup, removed following code fragment from supergroup.js:
// if (typeof require !== "undefined") {
// if (typeof underscore !== "undefined" && underscore === "underscore") {
// var _ = require('underscore');
// } else {
// var _ = require('lodash');
// }
// }
and it worked.
I'm not good in understanding how ember-cli dependencies work, so I'd like to understand what's going on and what's proper way to install Supergroup.js without brute force patching, adding dependencies in bower.json (or may be in package.json)
You don't have to include lodash in your bower.json, it's already specified as a dependency in supergroup. All the author meant (I'm assuming) is that it should be included first as far as javascript is concerned.
This is actually a much more complex issue than I had in mind. Basically supergroup.js attempts to figure out if it's being used with AMD modules or not using the code you commented out.
ember-cli converts ES6 modules into AMD modules through babel. So when supergroup.js is loaded it detects require and thus expects lodash to be available. It isn't!
Because ember-cli can't presently handle something referred to as anonymous AMD modules:
define([], function() {
return lib;
});
Which is what lodash does when it's figuring out what environment it's in and how to expose itself.
I tried compelling lodash into making itself available in a format that could be picked up by supergroup.js, but I don't think it's currently possible without changing either ember-cli, lodash or supergroup.js. I would really suggest you just use your edited version for now. There's various related issues causing this.
References:
https://github.com/artsyca/ember-cli-lodash/issues/3
https://github.com/ember-cli/ember-cli/issues/2949
http://blog.abuiles.com/blog/2014/10/03/working-with-javascript-plugins-in-ember-cli/
https://github.com/ember-cli/ember-cli/issues/2177
Looks like it works with ember-browserfy.
npm install --save-dev lodash
npm install --save-dev supergroup
//where needed
import _ from 'npm:supergroup';
and nothing in bower.json, Brocfile.js and .jshintrc!
Related
In the Jest tests for my React app in WebStorm, the following line
const { createMemoryHistory } = require("history");
has the following warning:
Module is not listed in package.json dependencies
The tests run as expected, they pass and fail as expected. createMemoryHistory works. And when I hover on history WebStorm actually shows me the documentation for the library.
(strike this:) But history is a native JS library, like fs, is it not? How do I fix this pesky warning?
UPDATE: Okay, I understand that fs is not a native JS library, it's a core node.js module. I was wrong and thanks for setting me straight on that.
I see that my package-lock.json does include an entry for "node_modules/history". It looks like it's two indents deep, but the lockfile is too complex for me to really tell, or get breadcrumbs, or fold the branch to see where this line falls in the tree.
So I guess the real question is, Webstorm is saying that I don't have the dependency, but the lockfile implies that I do. Unless I'm misunderstanding further.
Again, how do I fix this pesky warning? (or what other fact am I missing? Remember, everything does actually work).
fs is a core Node.js module, i.e. its code is compiled into Node.js binary and doesn't have to be installed. history library is a usual NPM module that is not a part of Node.js core and has to be added with npm i history(see https://github.com/remix-run/history/blob/main/docs/installation.md). The IDE just tells you that you are importing a module that is not listed among dependencies in your package.json
I am attempting to incorporate createJS into a typescript project (a powerbi visual) that I am building.
I have done the following:
1) Installed createJS and typings file using:
npm install createjs --save and npm install --save #types/createjs
2) Added this line to the the externalJS array in pbiviz.json : "node_modules/createjs/builds/1.0.0/createjs.min.js"
3) Added the path to the typings file to the files array in my tsconfig.ts file:
"node_modules/#types/createjs/index.d.ts".
Something didn't go right, I'm seeing the following error in my console:
This was without actually calling the namespace in my code, if I attempt to use the namespace then it simply breaks my code without any warnings. My IDE's auto-suggest offers createjsimplying to me that it was imported properly but still something isn't right.
I think its related to this thread but I don't understand how to implement the solution it typescript. Can anyone help?
My project structure:
It appears that the issue is an internal issue. I found a solution that I will not pretend to fully understand.
Starting from scratch, instead of installing the createjs package with the --save option I ran
npm install createjs-module --save and
npm install --save #types/createjs
which is apparently a webpack.
After this I "node_modules/createjs-module/createjs.js" in to my externalJS array, as well as the appropriate typings file to my tsconfig.json.
Credit to tsveti_iko
see also:
this
There are 2 methods to import createjs(not createjs specific)
This is what I use in my ts classes. For this you have to set compiler options module to system in tsconfig.json. This is what I use. I seems it's not the recommended one. It like an import statement(or maybe more like an include script)
tsconfig.json:
{
"compilerOptions": {
"module": "system",
.ts files using createjs:
/// <reference path="../lib/createjs.d.ts"/>
The other method is to use import statements along with commonjs. This is the recommended one. I was not able to make it work but didn't try too much because the first method is working.
https://www.typescriptlang.org/docs/handbook/compiler-options.html
Does anyone have a working example of a (simple) ember-app project built using Ember-CLI that uses LoDash? (e.g.: I want to use lodash, _.someLodashFunc, in my Routes and Controllers).
I haven't seen any thread / article on the web that gives clear, step-by-step explanation on how to do that.
If possible with lodash v3.0.0 (and I'm using the latest ember-cli, v0.1.9).
Thanks,
Raka
I found out how, you need to generate a custom build of lodash (the "lodash modern"). Use lodash-cli: https://lodash.com/custom-builds
On the command console type: lodash modern ..., and you'll get a javascript file generated: lodash.custom.js
Put that file under "vendor" dir of your ember-cli project.
Modify the Brocfile, add this:
app.import('vendor/lodash.custom.js', {
'lodash': [
'default'
]
});
And that's it.... you don't have to do "import _ from 'lodash'" in any of your js files. In fact, don't do that (you'll get an error). The _ var is readily available.
For example, I have a Route object like this:
import Ember from 'ember';
export default Ember.Route.extend({
model: function() {
console.log('hohoho: ' + _.chunk(['a', 'b', 'c', 'd'], 2));
return Ember.Object.create({name: 'Raka'});
}
});
And I could see hohoho:,b,c,d got printed in javascript console when I visited that route.
CORRECTION
You don't really need that lodash-cli.
I've tried this way (I guess more proper):
bower install lodash --save
In Brocfile.js, have this line: app.import('bower_components/lodash/lodash.js');
That's it. _ is automatically available in your Routers / Controllers.
I did the same with d3:
bower install d3 --save
In Brocfile.js, have this line: app.import('bower_components/d3/d3.js');
And variable named 'd3' is automatically available.
Added related link:
Import custom library in ember-cli
http://tiku.io/questions/2866484/how-to-include-a-local-javascript-im-ember-cli-application (quote: If you don't need them to minified in your vendor.js file you can put them in the public/js and then include it as a normal script file in app/index.html. I use this method for some libraries like moment.js. The public folder gets directly copied to your site root during the build.)
Proper way to access third party libs such as D3 in Ember CLI?
You can use something ready:
https://github.com/levanto-financial/ember-lodash
or do it manually.
I don't have any example but it should be as easy as modifying these 3 files:
bower.json
Just add the line
"lodash": "4.16.4",
to your dependencies and run bower install in your command line.
Alternatively, you can install it via bower:
$ bower install lodash --save
Brocfile.js
In order to be included to sources by Broccoli:
app.import('bower_components/lodash/lodash.js');
add this somewhere after var app = new EmberApp();
.jshint.rc
Add the line:
"_": true,
somewhere in the predef section (if you don't want to see the warnings like _ is undefined).
I haven't tested that but I hope it helps :)
You can install the latest stable version using Bower. In your project's root directory, run:
bower install lodash --save
Then import it using Brocolli by adding this line in your Brocfile.json somewhere after var app = new EmberApp( ...:
app.import('bower_components/lodash/lodash.js');
ember-lodash addon would be best pet.(https://www.npmjs.com/package/ember-lodash)
install addon : ember install ember-lodash
To include string functions alone
import _string from 'lodash/string';
let truncatedString = _string.trunc(rawString);
To include entire lodash library,
import _ from 'lodash/lodash';
let truncatedString = _.trunc(rawString);
Let's say I want to use Immutable in my project (or any given npm package). I have npm installed it, so it is in node_modules. Of course, it has CommonJS exports there. I, however, want to use es6 modules in my project.
I am using Webpack to compile it all together, with the 6to5-loader to deal with es6 module syntax.
In my source file, I say import Immutable from 'immutable'; --- but this causes a problem because the es6 import is looking for an es6 default to have been exported, which isn't the case (for Immutable or probably almost any other npm package). The compiled code ends up looking like this: var Immutable = require('immutable')["default"]; --- which of course throws an error, since there is no default property to find.
Can I consume the npm packages with es6 modules?
Babel.js contributor here. You're looking for the following:
import * as Immutable from 'immutable';
// compiles to:
var Immutable = require('immutable');
Interactive demo
Note: This is with either the common or commonInterop modules option. For others, see: https://babeljs.io/docs/usage/modules/
Just figured it out. (The solution is tool-specific --- but es6 modules only exist now insofar as they are tool-enabled, so I think that's enough of an "answer".)
6to5's default module transpilation uses the common option, which results in the very problem I griped about above. But there is another option: commonInterop --- which must have been built to deal with exactly the situation I'm dealing with. See https://6to5.github.io/modules.html#common-interop
So three cheers for 6to5.
So this is a really basic question. In all my blueprinted files, I see import statements such as:
import DS from 'ember-data';
Now I know that the build process is finding these in the vendor directory where bower installed them. Recently, I added moment.js, and I'd like to create a helper using it. However, there must be an additional naming convention that's being used because I can't simply
import moment from 'moment';
-- it claims it cannot find it in the tree merger. What is the right way to tell Broccoli where to find things when I want to import them?
Here is how I got things to work.
Install moment.js using bower install
Add the following line in Brocfile.js
app.import('vendor/moment/min/moment.min.js');
In your code, you do NOT have to import moment as it is NOT a ES6 module. You can call moment directly. For example,
var currDate = moment();
In the files where you use moment, don't forget to add the below comment as the first line of your file. You need to do this to avoid the jshint errors shown by ember-cli when you build the code
/* global moment:true */
Hope this helps!